Monthly Archive for August, 2009

Page 2 of 2

Wrong Way Warrior: Getting Flexibility with Design Patterns—Part II

Gentle Reader: This is the second part of a two-part set of posts. For this one to be useful, please take a look at Part I. Also, I’m not an expert on military operations or organizations; so if there’s any error in a basic infantry platoon, feel free to correct me. I am aware, however, of the 7-1 ratio of Service to Combat units in the modern military, and that this is only a simple component of a far more sophisticated structure—that’s why I selected it!

In the first installment of the Wrong Way Warrior, we saw how an OOP developer put together a simple proof-of-concept using what he thought was a prudent approach to a battle simulation. He’d provide the Warrior with certain characteristics and then subclass those characteristics to concrete warriors that would share the capabilities of the parent class. In addition, the concrete warriors would be given a movie clip representation of the warrior.

After the first design was sent to the customer, the response was less than favorable. It was described as “a children’s game” at best. The military advisor described it as a caveman battle plan where all of the combatants are similarly armed with a club to attack adversaries. The problem was that it was bound to a fairly static design, and it would be impossible to be used for a simulation that had more complex behaviors. However, the other submissions were not much better, and so the customer provided a simple organization within the military to simulate—the basic infantry platoon. After all, they’re paying your company $1.5 million to develop the simulation. (This was news to the developer!) Figure 1 shows the organization in terms of a new set of movie clips:
platoon
Figure 1: Movie clip representation of platoon
Continue reading ‘Wrong Way Warrior: Getting Flexibility with Design Patterns—Part II’

The Wrong Way Warrior: Where OOP Alone is Not Enough—Part I

In preparing for this year’s OOPSLA conference where my session will focus on demonstrating good practices by showing examples of poor practices, I was reminded of the first chapter of the Freemans’ wonderful book, Head First Design Patterns (O’Reilly). To introduce the reader to design patterns in Java, the Freemans set up an example where a developer got in trouble because his program could not be expanded or changed without taking the whole thing apart and putting it back together again. In their wisdom, the Freemans wanted to kick things off with practical reasons for using design patterns—not just because doing so is the right thing to do.

In some recent discussions, I’ve heard references to OOP and design patterns as a religion or mockingly called “doing it right” as though design patterns are some kind of moral imperative by obsessive-compulsive developers rather than practical solutions to programming problems. Any kind of programming solution should be a solution that does a good job of solving a problem and nothing more. Discussions of OOP and design patterns as the right way to get things done has no resonance with me at all; so I’m the wrong person to suggest that faith in design patterns is sufficient reason to use them.
Continue reading ‘The Wrong Way Warrior: Where OOP Alone is Not Enough—Part I’