Title: The Pet Project (part 4)

The Design Patterns book, ref [GoF], describes the intent of the Builder pattern as: "To separate the construction of a complex object from its representation so that the same construction process can create different representations."

It seems a laudable intent just to "separate the construction of a complex object from its representation", regardless of the fact it has different representations or not.

I have not yet experimented with the use of the Builder pattern so cannot really comment further but, although Builder keeps the construction process separate, it does not undo any of the complexity of the construction process.

A Builder pattern will probably get considered in my UML version - see later comment - and we will see then how successful it is.

It has already been mentioned about the dilemma of construction of ColourGroups and AssetSites. What happens when we have default constructors for these classes? We must fix-up attributes or associations after the object's construction.

So we might have:

AssetSite oldKentRd;
AssetSite whitechapel;

ColourGroup darkBrownColourGroup;

oldKentRd.name = "Old Kent Road";
oldKentRd.colourGroup = 
                darkBrownColourGroup;
whitechapel.name = "Whitechapel";
whitechapel.colourGroup =
               darkBrownColourGroup;

darkBrownColourGroup.Add (oldKentRd);
darkBrownColourGroup.Add (whitechapel);

I will not go on at this point. As you can see it is getting long winded. It could be made a little simpler by using an Initialise method rather than do attributes one by one. Anyhow my gut feeling still is not happy with this approach so I will dismiss it in the belief that there must be a better way.

The original coupling came about because, when landing on a Site an Action^[2] was required, e.g. when landing on an AssetSite the Action required is to collect rent on behalf of the Site's owner. In this case the Site needs to know about all the other Sites in the same colour group because if they are all owned by the same owner then the rent may get doubled.

If the Action of rent collection is handled differently then the Site may not need any knowledge of the colour group. We will be looking at this further in this article when the Visitor pattern is discussed. It will also get considered during the UML design.

In the original implementation the AssetSite class actually has two uses. In one instance it was used for a site that had visitors and, when a player lands on the site some action occurs (collecting rent). In the other instance they represented an Asset owned by a player.

We can deal with the first use quite quickly, as we have already briefly mention decoupling and the possibility of executing the Action in a different manner. Hopefully it will resolve itself that - in addition to a Site not requiring knowledge of its ColourGroup - it may not need to know about its visiting Players.

Figure 1. Separating the TitleDeed asset from the site.

Figure one shows one possibility of separating an AssetSite and TitleDeed. What advantages could this bring? Well houses and hotels are assets, a player's cash is an asset and even a get out of jail free card could be a useful asset at some stage. This is shown in figure two.

Figure 2. Further assets

This would be useful when tallying a player's assets from a std::set<Asset*> for example, where it is not necessary to worry about the type of the asset, merely its value.

One of the issues I did not like with the original implementation was how information regarding the current state of play was stored and which parts dealt with the control of the game.

Basically the current state of a game was held in a number of global variables, which were accessed by whichever class needed the information.

The purpose of model-view-controller is to separate the data from user control and views of that data.

Figure 3. Simple Model-View-Controller relationships

Initially it seems logical to wrap the global data into a class (MonopolyDocument for example) that is responsible for not only holding the game state, but also saving and restoring the data to / from a file. This defines the model for the game.

Any view of the game simply reads the data from the document. This is probably a case for the Observer pattern, whereby the views are observers of the MonopolyDocument subject (see ref [GoF]).

Control of that data seems a little more complicated. It could be performed through a GameManager, which is responsible for keeping the data in the MonopolyDocument in a consistent state. Any menu-item clicks or button pushes correspond to a call of a GameManager method. But this is not as simple as it sounds - let us take a look at the action required when a player lands on a community chest or chance site. When this occurs the current player must obey the instructions on the card.

For most cards this is easily handled, but sometimes the player must make a choice (buy or sell the "Get out of Jail free" card). In all cases it is necessary to display the card to the actual player so they know what is happening.

So what is responsible for creating the view of the card? If the GameManager is truly separated from views then it should not create the window. The game might be running as a console application, Windows application or even an Internet application so who knows how the card gets displayed to the player? Also, as can be seen from figure 3, the view and controller classes are completely separated.

But this would mean that each of the states - a) picking up the card, b) choosing a response^[3], c) performing the action and d) replacing the card - would have to be known by and recorded in the document. This seems a bit extreme.

Figure 4. Another "view" of the Model-View-Controller relationships

Ref [GoF] indicates that each View has an instance of a Controller (figure 4). The reason given is so that views can give different responses simply by using different controllers. This is not quite the situation we are looking at, but it may be the Strategy pattern (the interaction between Controller / View) may help in performing the action required when landing on a CardSite.

Yet again I shall leave any further decision making here until it gets reconsidered during my UML design.

In the second article I described what happens when a player lands on a site or picks up a chance / community chest card. The site and card^[4] classes have a virtual function (called Action) which gets called. That function is then responsible for carrying out the required action. This means that the sites end up having intimate knowledge of pretty much all the other classes in the program. The Visitor pattern helps eliminate this highly coupled state of affairs. (The pattern is described in refs [GoF] and [Vlissides]).

Using the Visitor pattern the site passes responsibility back to a third-party - a SiteManager say. The SiteManager can then perform the action required, probably via the aforementioned GameManager.

So the sequences of events becomes:

Figure 5. Using the Visitor pattern

In this way Sites need only know about the SiteManager class. The SiteManager will know what actions need be called on from the GameManager on behalf of the particular type of Site. The SiteManager's Visit function is specific for different site types, so we have:

class SiteManager {
public:
  SiteManager ();
  void Visit (GoSite&);
  void Visit (BuildingSite&);
  void Visit (CardSite&);
// etc
};

Each concrete Site class must implement the Accept function, e.g.

void CardSite::Accept (SiteManager& sm){
  sm.Visit (*this);
}

Up to this point I have been discussing ideas of how things might be done. This is very much how the original game was produced all those many years ago. An idea was settled on, which seemed to fit together, and the programming started.

It is design - of a sort, but the only rationale behind the choice of classes was that they seemed correct and that I was able to produce a working implementation of the game.

Some of the things I did not like about that design have been mentioned here, but this does not mean that the alternatives are better - just different.

References Cargill, Meyers, and Meyers2 discuss various aspects of these issues and put forward solutions for relatively simple examples to help illustrate their point.

With this Pet Project applying those solutions is not always straightforward because of other interactions required between the classes. However, the benefits of simply trying out the solutions are:

Unfortunately, and unlike this project, real-life time-scales and budgets often compromise some design decisions. But one is at least able to gauge the knock-on effects of any compromises made.

So we have done design (of a sort - as mentioned), but it has not been formal. The original implementation ended up with far too much coupling between the classes, and even some of the "solutions" discussed will not necessarily give the cleanest design and I would like to aim for the best and simplest design^[5].

As you can see above, a lot of decision making has been left until the UML design is performed - as if UML is some kind of Utopia that will magically iron out all the problems discussed so far. I cannot say for certain if it will, but the purpose of The Pet Project is to be used as a real project to see how new languages, methodologies, techniques etc can be used both effectively and pragmatically.

Ref [Martin] gives a very interesting case study for the design of a Building Security Manager. I have started to use this same approach for Monopoly and am documenting each step and each decision being made during the design. I have tried to step back to square one and start the whole thing off from scratch, without any pre-conceived ideas on classes required and what their interactions will be. I will find it interesting to see what differences exist in the final design and implementation when compared to the dive-in approach I have taken so far.

Initially the UML Toolkit (ref [Eriksson-]) version of Rational Rose V4.0 was used, but its limitations in the number of use-cases and classes allowed were quickly reached. A couple of trial editions of other UML tools, UML-Magic and, very recently, WithClass^[6]. To date I have yet to find one that gives me all the facilities I am after in such a design tool - so perhaps I'll have to write one - unless someone can recommend a better one.

I intend to submit my UML design to Overload when it is complete, but given the number of years I have being playing with C++ I guess you should not hold your breath - I might be playing with UML until I retire.