Tag Archives: Class (computer programming)

Behavioural software patterns

2 Comments

These patterns cover algorithms and the assignment of responsibilities between objects.

Iterator – this pattern is concerned with allowing iterative access to a composition without exposing the underlying implementation.

Typically an iterator is an abstract interface and the composite object creates a concrete iterator that implements it – but the iterator interface is what is used by other objects.

Mediator – the mediator pattern is concerned with ensuring loose coupling between objects by defining interfaces that allow them to interact without knowledge of each others’ internals.

Observer – this pattern defines a one-many dependency in which one object – called the subject – notifies subscribing objects of changes in its state.

UML to describe the Observer pattern

From Wikipedia

State – this pattern is about allowing an object to change its behaviour when its state changes. The object will appear to change its class.

The Gang of Four give the example of a TCP connection – which will respond differently to datagrams depending if it is in the LISTEN, ESTABLISHED or CLOSED state. In each of these cases a different subclass will handle behaviour, though a common interface is used by all three.

UML for state pattern

From Wikipedia

Strategy – this pattern allows objects with different algorithms to operate through a common interface. Typical examples in text books and lecture notes are including paper aeroplanes and rubber ducks in collections of aircraft and avians!

So, for instance, all aircraft may have a fly() method in their abstract interface, but the concrete implementation for the paper aeroplane implements behaviour appropriate for that type of craft.

UML for strategy pattern

From wikipedia

Template Method  - this pattern creates a skeleton for an algorithm but allows subclasses to over-ride specific parts.

Template method UML Class Diagram

Image via Wikipedia

Visitor – the visitor software pattern is concerned with allowing new algorithms to be applied to an object without changing the object itself. Instead a new visitor class implements the visitor interface. In this way many new methods can be dynamically added to a class.

Class Diagram for the Visitor Pattern

Image via Wikipedia

Related articles

Creational patterns

1 Comment

The Gang of Four list the following creational patterns:

Abstract Factory – an interface for creating families of related or dependent objects without specifying their concrete classes – the example the Gang of Four give is of an abstract factory that produces “abstract widgets” (ie display artefacts) that can then be subclassed to the particular look and feel of the display (the book shows its age by referring to Motif and Presentation Manager as choices, but the principle is unaltered). This pattern can be used when a system should be independent of how its products are created and represented, or when a library of software objects is needed but one wishes only to expose the interface and not the implementation.

Abstract Factories have a certain inflexibility though – to add a new output object it is necessary to change the interface and that also means changing all the concrete subclasses, as they have to match the interface of their abstract parent.

Builder - this separates the construction of a complex object from its representation, so allowing one construction process to create many different representations.

Builder software pattern

From wikipedia

Factory – defines an interface for creating an object but lets subclasses decide which class to instantiate.

Factory pattern in UML

From wikipedia

Prototype creates a prototypical instance and new objects are instantiated by copying this prototype.

The Gang of Four give an example of a musical score editor, which might create graphic elements to add to the score – but instead of the editor needing to have a subclass for every type of musical object to be added, it calls a parameterised clone method on a graphic (abstract) class that creates a copy of the concrete element sought.

UML for prototype pattern

From wikipedia

Singleton – a pattern to ensure that there is only one instance of a given class and that there is a universal point of access to it.

Often implemented using static methods in the real world:

class Spooler {
private spooler = 0
static Spooler getSpooler() {
if (spooler == 0)
spooler = new Spooler()
return spooler
}
protected Spooler() {
…some initialisation code…..
}
}

Related articles

GRASP software patterns

2 Comments

This is a UML diagram (created in IBM Rhapsody...

Image via Wikipedia

My final exam is on Tuesday and covers object-orientated design and programming – hence the Groovy Game of Life code.

Software patterns are a big part of the course and part of that is the simple task of remembering what each pattern does. I have found Head First Design Patterns useful but it covers few patterns and certainly not the basic GRASP ones, that I do have to know.

GRASP stands for General Responsibility Assignment Software Patterns (or Principles – I actually think this comes closer to expressing what this is all about anyway).

These are:

Information Expert, solving the problem of the general principle of assigning responsibilities to objects by assigning the responsibilities to the information expert – the class that has the information necessary to fulfil the responsibility.

Creator, solving the problem of what should be responsible for creating a new instance of some class by assigning the responsibility of creating a new instance of class A  to the class, B, that:

  • aggregates A objects; or
  • contains A objects; or
  • records instances of A objects; or
  • closely uses A objects; or
  • has the initialising data that will be passed to A when it is created.

(If more than one class displays these characteristics then aggregation or composition should be preferred.)

Low Coupling, solving the problem of creating classes that have low levels of dependency and face a low impact when other classes are changed and can be more easily reused by assigning responsibilities so that coupling remains low.

Controller, which addresses the question of what should be responsible for handling an input system event by assigning the responsibility to a class that represents one of the following choices:

  • It represents the overall system, device or subsystem (it is a facade controller); or
  • It represents a use case scenario within which the system event occurs, often named Handler or Coordinator, etc (it is a use-case or session controller).

High Cohesion, which addresses the problem of how to keep complexity manageable and how to keep objects focused by assigning responsibilities so that cohesion remains high.

Related articles