Overview Of The Used Design Patterns

• all the "Simple"Classes
• ActionKnowledgeCatalog
• ConstructionKnowledgeCatalog
• EvolutionKnowlegdeCatalog
• ResourceKnowledgeCatalog

Since a class is a special (managing) kind of object, it is managed by a special class called ``meta-class'' (which manages itself). The meta-class is used to create and to instantiate ordinary classes. By modifying meta-classes it is possible to change the behavior of the derived classes widely. All inter-object and inter-class relationships are completely dynamic and can be changed at arbitrary times.

We used this to model the Simple Classes, a Simple Class has some standard behaviour which is implemented in the class and which mainly exists out of algorithms calling template methods. In these algorithms certain knowledge has to be used about the class, that's where the KnowledgeCatalog's come into play: they provide the simple classes with the insight information they need.

• All the Knowledge Catalogs
• Eventmanager
• World
• Evolution

To ensure that those classes have only one instance, and provide a global point of access to it. The Singleton pattern ensures that only one instance of a class is created. All objects that use an instance of that class use the same instance.

The KnowledgeCatalogs and the EventManager are true singleton classes, there can only be one instance. For the World object (and its dependant Evolution) this is mainly used to simplify access to those classes (without double bindings).

• WorldController

To provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. This pattern is used to simplify a number of complicated object interactions into a single interface. It simplifies access to a related set of objects by providing one object that all objects outside the set use to communicate with the set.

To not overload our central design class World, we introduced a controller class for it. This is the main object used in communication with the userinterface.

• ImageCache

To use sharing to support large numbers of fine-grained objects efficiently. If instances of a class that contain the same information can be used interchangeably, the Flyweight pattern allows a program to avoid the expense of multiple instances that contain the same information by sharing one instance.

To load graphics and manipulate graphics context we use javax.swing.ImageIcon objects. We noticed that this slowed down our application a lot, but because we saw no immediate simpler (and less loaded) method, we decided to cache the image loading. With success!

• The whole design

The gui only knows about the classes InfoList, EventManager and WorldController. InfoList acts as a help class for transfering information to the gui. The WorldController only gives information to the gui about the names of the different actions and constructions. A WorldController can also give information about a selected square, human or construction. It will also tell if the value (e.g. forest) of a name (e.g type of land) is a boolean, percentage or string. The gui can than choose how to display this information.

The gui is not a mirror of our model! The only thing that a gui really knows about the model is the size of the gameboard because a gui will create the worldcontroller which instanciates the singleton world. The painting of the right state of a square is done implicit. If a square changes in the model, it will fire a squareChangedEvent. This event is passed to the gui.GameBoard and it can ask the events for information.

For example if a land type of a square is changed the gui can ask the fired squareChangedEvent the land state that will return a string (e.g. Forest). From the name of the string the gui knows wich type of image it will use to paint the square (e.g. Forest.gif). This way the model will have nothing to do with how a square will be painted on the gameboard of the gui.

• ImageCache

The Proxy pattern forces method calls to an object to occur indirectly through a proxy object that acts as a surrogate for the other object, delegating method calls to that object. Classes for proxy objects are declared in a way that usually eliminates client object's awareness that they are dealing with a proxy. Proxy is a very general pattern that occurs in many other patterns, but never by itself in its pure form.

Just a design artefact of a cache.

• Eventmanager

The Mediator pattern uses an object to coordinate state changes between other objects. Putting the logic in one object to manage state changes of other objects, instead of distributing the logic over the other objects, results in a more cohesive implementation of the logic and decreased coupling between the other objects.

This of course used due to the model/view separation.

• Eventmanager

Allow objects to dynamically register dependencies between objects, so that an object will notify those objects that are dependent on it when its state changes.

This of course used due to the model/view separation.

• several evolve methods use a template method _evolve
• the perform method of action uses a template method _perform
• a lot of abstract parent classes of our Simple classes use template methods to simplify extending the game

To write an abstract class that contains only part of the logic needed to accomplish its purpose. We organized the classes so that its concrete methods are implemented template methods, now a concretion for the parent method where the missing logic is represented by template methods. The missing logic is provided in the subclasses' methods that override the abstract method.