Contract abstraction

I am puzzled about adding another layer of abstraction to my dice simulator, a contract that enables the code to slip easily between changes to my GUI and my data.

Perhaps two sets of Model, View, Controller? One set for a basic program to receive user input, and another set which varies according to the user’s input?

Depilatory programming

My Shadowrun Dice Simulator vexes me in several ways, all to do with object-oriented design:

• the user's choice of test affects the user interface as well as the object representing the test data
• the user's choice of test parameters affects the user interface as well as the object representing the test data
• accordingly, the construction of the user interface depends on a number of conditions
• similarly, the construction of the object representing the test data depends on a number of conditions
• this raises the consequent question of how the MVC architecture can be satisfactorily implemented

Well, I'm on the cusp of something. I don't know what it is but my mockups - JFrames, JDialogs, etc - make for a nice application. It's a matter of applying object-oriented design principles properly. Goodness knows how I am going to do that, with Stackoverflow.com unhelpful on such things.

Encapsulate what varies: the choice of test, the choice of test parameters, the user interface, the object representing the test data.

Abstract Factory Pattern

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

This pattern saves clients the bother of instantiating families of products. The client is written against an abstract factory interface. The interface, which creates products in the abstract, is implemented in concrete factories which create the particular families of products from concrete implementations of abstract product classes.

One question I have is whether the client needs to also be written against the abstract product classes, as the Wikipedia article on this pattern suggests.

Decorator Pattern

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Subclassing components would extend functionality at compile time. Fortunately, however, the Decorator Pattern does this at run time. The pattern means that classes are open for extension but closed for modification.

This pattern wraps a concrete component with one or more decorations, or additional responsibilities. Decorations are derived from an abstract decorator class which in turn inherits from an abstract component superclass.

The concrete decorator class is passed a component in its constructor, so that operations inherited from the abstract component superclass can build on - decorate - the component.

An implementation of the Decorator Pattern carries with it an assumption that the abstract component superclass type is satisfactory to the rest of your code. You should consider another pattern if the concrete component type is what the rest of your code depends on.

Observer Pattern

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

This pattern is useful for the loosely coupled way it disseminates the fact of a data event or data change in a single subject to as many observers of that subject as have subscribed to receive such notifications.

Apparently, usual practice is for observers to "pull" data from the subject rather than for the subject to "push" the data to observers; in other words, usual practice is for the subject to have getter methods for its state rather than send its data as a parameter in a notifyObservers() call.

A concrete subject implements an interface to register, unregister and notify observers and has a list of registered observers that receive notifications. Concrete observers of the subject implement an interface to update themselves or other objects upon receiving notification of data events or changes in the subject.

Strategy Pattern

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

This pattern is a means of exchanging members of a family of algorithms without impeding the operation of clients. It requires programming to an interface, not an implementation. The pattern grants clients consistency because concrete algorithms in use are members of the same family or interface.

Head First Design Patterns implements Strategy Pattern in an interesting way. Rather than provide a class with behavioural methods, they have the class delegate behaviour to an interface. Concrete behaviours have to implement their particular interface. As a result, ducks behave appropriately!