Question

So, I’ve come back to ask, once more, a patterns-related question. This may be too generic to answer, but my problem is this (I am programming and applying concepts that I learn as I go along):

I have several structures within structures (note, I’m using the word structure in the general sense, not in the strict C struct sense (whoa, what a tongue twister)), and quite a bit of complicated inter-communications going on. Using the example of one of my earlier questions, I have Unit objects, UnitStatistics objects, General objects, Army objects, Soldier objects, Battle objects, and the list goes on, some organized in a tree structure.

After researching a little bit and asking around, I decided to use the mediator pattern because the interdependencies were becoming a trifle too much, and the classes were starting to appear too tightly coupled (yes, another term which I just learned and am too happy about not to use it somewhere). The pattern makes perfect sense and it should straighten some of the chaotic spaghetti that I currently have boiling in my project pot.

But well, I guess I haven’t learned yet enough about OO design. My question is this (finally. PS, I hope it makes sense): should I have one central mediator that deals with all communications within the program, and is it even possible? Or should I have, say, an abstract mediator and one subclassed mediator per structure type that deals with communication of a particular set of classes, e.g. a concrete mediator per army which helps out the army, its general, its units, etc.

I’m leaning more towards the second option, but I really am no expert when it comes to OO design. So third question is, what should I read to learn more about this kind of subject (I’ve looked at Head First’s Design Patterns and the GoF book, but they’re more of a “learn the vocabulary” kind of book than a “learn how to use your vocabulary” kind of book, which is what I need in this case.

As always, thanks for any and all help (including the witty comments).

Answer 1

I don’t think you’ve provided enough info above to be able to make an informed decision as to which is best.

From looking at your other questions it seems that most of the communication occurs between components within an Army. You don’t mention much occurring between one Army and another. In which case it would seem to make sense to have each Mediator instance coordinate communication between the components comprising a single Army – i.e. the Generals, Soldiers etc. So if you have 10 Army‘s then you will have 10 ArmyMediator‘s.

If you really want to learn O-O Design you’re going to have to try things out and run the risk of getting it wrong from time to time. I think you’ll learn just as much, if not more, from having to refactor a design that doesn’t quite model the problem correctly into one that does, as you will from getting the design right the first time around.

Often you just won’t have enough information up front to be able to choose the right design from the go anyway. Just choose the simplest one that works for now, and improve it later when you have a better idea of the requirements and/or the shortcomings of the current design.

Regarding books, personally I think the GoF book is more useful if you focus less on the specific set of patterns they describe, and focus more on the overall approach of breaking classes down into smaller reusable components, each of which typically encapsulates a single unit of functionality.