Objective 8.1: From a list, select the most appropriate design pattern for a given scenario. Patterns will be limited to those documented in Gamma et al. and named using the names given in that book

decision making which returns several possible subclasses based on a hint. Sub-classes decide which class to create.

an interface to a Factory for several families of related objects. Use when want to create a bunch of classes together, if just want one object then use Factory Method, eg: EJBHome.

separate construction of complex objects from representation, so several representations can be created.

copy or clone an object to recycle it. From the client’s point of view it doesn’t know how and by whom the objects are being created. No need for factories to create objects.

single instance, global point of access, could have controlled number of instances.

convert the programming interface of one class to another. Allows unrelated classes to work together easily. Class that exposes an nice interface and wraps and calls another class. The intent is to make classes look the same as a particular class. Allows classes to work together that wouldn’t be able to because of incompatible interfaces.

to represent a part or collection of parts.

do not store all the details of an instance as attributes. Instead have just the intrinsic stuff as attributes and pass the other 'extrinsic' details as part of a method call. The intrinsic stuff is in the class and no need to create a complex inheritance hierarchy just re-use the same class because it doesn't have the unused attributes. Each object does not hold isn't own state, instead held externally.

Provide a simple interface to a complex framework of classes, eg: JDBC interface. Eg: surrogate or placeholder for remote class.

Wrap another object, pass calls on, but can postpone creation of the wrapped object, cache, etc. Eg: EJB, RMI stubs and EJBObject.

Like an adapter but designed to separate the interface from the implementation without changing the client code. Allows interface and abstraction to vary. Eg: JNDI and Business Deligate.

modify the behaviour without having to create a new derived class. The decorator calls a specific decorator instances to add their decorations as required. Kind of delegate to another class some aspects of the object that may be changeable. Note: the composite pattern in it.

objects that contain the data are separate from the objects that display the data. The observers observe changes in the data (subject). The observers register an interest in the subject and it calls the observers back when something changes. Publish/Subscribe pattern.

to avoid too much inter-class dependency use a mediator intermediary class. This class is informed of changes and it in turn informs those classes with an interest. Prevents every class needing to know about all the other classes.

a chain of classes where a request is passed to them all. The class with an interest in a particular request then deals with it. The chained classes do not need to know about each other. The sender is de-coupled from the receiver.

define an algorithm in a class but leave some details to be implemented by a sub-class. Some parts of the algorithm in the base others in the derived classes.

capture and store an object’s internal state. The client uses the origination class but wants keep it’s state without breaking encapsulation. So, it asks it to create a small bean momento object. Then the client gives this to another class to take care of it. Later, if the client wants to restore the origination to it’s old state it passes the old momento to the originator and it copies the state back into itself.

when you pass a query string to a class, it interprets the string and performs the operation. The interpreter handles parsing, etc and produces varying kinds of output. Note: the composite pattern in it.

encapsulate algorithms in a class, the class chooses the correct algorithm for the particular context. Similar to state, state is a strategy with only state algorithms.

adds a function to a class. Instead of putting the code in multiple classes, such as a draw method on Square and Triangle, simply write another class with it in and get the Square and Triangle to call the public draw method of the visitor. Adds functionality without changing the class. Allows you to centralise things on place not multiple classes with similar algorithms, etc.

similar to strategy except to do with switching between states. The class encapsulates the state transitions.

separate execution of a command from the interface. Separate controller logic and allows plug-able new commands and undo. Encapsulate a request in an object.

move through a list using standard interface without worrying about internal representations of the data. Eg: Resultset.