1. More Design Patterns 1

2. Additional Patterns
Null
Singleton
Composite
Decorator

3. Null Object Pattern Intent Participants
Provide an object as a surrogate for the lack of an object of a given type.
The Null Object Pattern provides intelligent do nothing behavior, hiding the details from its collaborators
Participants
AbstractClass
defines abstract primitive operations that concrete implementations have to define
RealClass
a real implementation of the AbstractClass performing some real actions
NullClass
an implementation of the AbstractClass but will do nothing, in order to provide a non-null object to the client
Client
the client gets an implementation of the abstract class and uses it. It doesn't really care if the implementation is a null object or a real object since both of them are used in the same way

4. Null Object Pattern Applicability
The Null Object Pattern is used to avoid special if blocks for do nothing code, by putting the “do nothing” code in the Null Object which becomes responsible for doing nothing. The client is not aware anymore if the real object or the null object is called so the 'if' section is removed from client implementation.
The Null Object design pattern is more likely to be used in conjunction with the Factory pattern. The reason for this is obvious: A Concrete Classes need to be instantiated and then to be served to the client. The client uses the concrete class. The concrete class can be a Real Object or a Null Object.

5. Class Diagram Component void request( ) Component void request( )
RealComponent
void request( )
NULLComponent
void request( )
void request () {
// do nothing }

6. Singleton Pattern Intent Applicability Consequences
Ensure a class only has one instance, and provide a global point of access to it.
Applicability
Use Singleton pattern when
There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point
When the sole instance should be extensible by sub-classing, and clients should be able to use an extended instance without modifying their code
Consequences
Controlled access to sole instance
Singleton class encapsulates its sole instance and has strict control over how and when clients access it
Reduced name space
It avoids polluting the name space with global variables that store sole instances
Permits refinement of operations and representation
It can be subclassed

7. Singleton Pattern – Example code
Implementation of Singleton
class SingletonExample {
private static SingletonExample _instance;
public static SingletonExample Instance
get
if (_instance == null)
_instance = new SingletonExample();
return _instance; } …

8. Composite Pattern Applicability Participants Component Leaf Composite
You want to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly
Participants
Component
declares the interface for objects in the composition
implements default behavior for the interface common to all classes, as appropriate
declares an interface for accessing and managing its child components
Leaf
defines behavior for primitive objects in the composition
Composite
defines behavior for components having children.
stores child components
implements child-related operations in the Component interface

9. Composite Pattern Collaborations Consequences
Clients use the Component class interface to interact with object in the composite structure. If the recipient is a Leaf, then the request is handled directly. If the recipient is a Composite, then it usually forwards request to its child components, possibly performing additional operations before and/or after forwarding
Consequences
Defines class hierarchies consisting of primitive objects and composite objects. Wherever client code expects a primitive object, it can also take a composite object.
Makes the client simple. Clients can treat composite structures and individual objects uniformly.
Makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code.
Can make your design overly general. It makes it harder to restrict the components of a composite.

10. Class Diagram Equipment Client * CompositeEquipment CDDrive FloppyDisk
Operation( )
Add(Component)
Remove(Component)
GetChild(int)
Client *
CompositeEquipment
Operation( )
Add(Component)
Remove(Component)
GetChild(int)
CDDrive
Operation( )
FloppyDisk
Operation( )
For all g in children
g.Operation( );

11. Composite Pattern – Example code
class FloppyDisk : public Equipment {
public:
FloppyDisk(const char*);
virtual ~FloppyDisk( );
virtual Watt Power( );
virtual Currency NetPrice( );
virtual Currency DiscountPrice( ); }
class Equipment {
public:
virtual ~Equipment( );
const char* name( ) { return _name; }
virtual Watt Power( );
virtual Currency NetPrice( );
virtual Currency DiscountPrice( );
virtual void Add(Equipment *);
virtual void Remove(Equipment *);
virtual Iterator<Equipment*> * CreateIterator( );
protected:
Equipment (const char * );
private:
const char * _name; }
class Chassis : public CompositeEquipment {
public:
Chassis (const char* );
virtual ~Chassis( );
virtual Watt Power( );
virtual Currency NetPrice( );
virtual Currency DiscountPrice( ); }

12. Composite Pattern – Example code
class CompositeEquipment: public Equipment {
public:
virtual ~CompositeEquipment();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment *);
virtual void Remove(Equipment *);
virtual Iterator<Equipment *> * CreateIterator();
protected:
CompositeEquipment(const char *);
private:
List<Equimpent *> _equipment; }
An implementation of NetPrice( )
Currency CompositeEquipoment::NetPrice() {
Iterator<Equipment *> * i = CreateIterator();
Currency total = 0;
for (i->first(); i->isDone(); i->next())
total += i->currentItem()->NetPrice(); }
delete i;
return total;

13. Composite Pattern – Example code
Assume we have additional Equipment classes such as Bus, Cabinet, etc. We can assemple equipment into a (simple) computer (CompositeEquipment object)
Cabinet * cabinet = new Cabinet(“PC Cabinet”);
Chassis * chassis = new Chassis(PC Chassis”);
cabinet->Add(chassis);
Bus * bus = new Bus(“MCA Bus”);
bus->Add(new Card(“100 Mbs Ethernet”) );
chassis->Add(bus);
chassis->Add (new FloppyDisk(“3.5 in Floppy”) );
cout << “ the net price is “ << chassis->NetPrice() << endl;

14. Decorator Pattern Intent
Allows the programmer to add responsibilities to individual objects, not to an entire class. The decorator conforms to the interface of the component it decorates so that its presence is transparent to the component’s clients

15. Class Diagram Component operation( ) ConcreteComponent operation( )
Decorator
operation( )
component.operation();
ConcreteDecoratorA
operation( )
addedState
ConcreteDecoratorB
operation( )
addedBehavior( )
base.operation();
addedBehavior();

16. Decorator Pattern Participants
Allows the programmer to add responsibilities to individual objects, not to an entire class. The decorator conforms to the interface of the component it decorates so that its presence is transparent to the component’s clients
Component
Defines the interface for objects that can be “decorated”
ConcreteComponent
Defines an object to which additional responsibilities can be added (can be “decorated”)
Decorator
Maintains a reference to a Component object and defines an interface that conforms to Components interface.
ConcreteDecorator
Adds responsibilities to the Component.

17. Decorator Pattern Consequences More flexible than static inheritance
Avoids feature-laden classes high up in the hierarchy
Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects
A Decorator and its Component are not identical
A decorator acts as a transparent enclosure

18. ?

19. References