SE311 Design Patterns

OBJECT ORIENTED DESIGN PRINCIPLE:

************************************************
ITERATOR PATTERN:
Iterating over Lists:
- The List class is not cohesive (we have combined the list and the iteration abstractions in one class).
- It complicates the list interface (we must add four methods to the interface).
- It assumes a particular ordering (if we want to iterate over the list in two directions, we must provide two sets
of methods in the list).
- Only one client can iterate at once (concurrent iterations will interfere with one another).
--------------------------------------------------------------------------------------------------------------------------------------
+ Different iterators can give different sequential ordering. Support variations in the traversal of a container.
- Iterators do not create a copy, modify it and iterate over the copy.
- Iterators do not modify the original collection.
--------------------------------------------------------------------------------------------------------------------------------------
Applicability:
-To support traversals of aggregate objects without exposing their internal representation.
-To support multiple traversals of aggregate objects.
-To support multiple simultaneous traversals.
-To provide a uniform interface for traversing different aggregate structures (to support polymorphic iteration).
--All iterator objects should provide the same interface for accessing and traversing elements, regardless of the
class of the aggregate object and the kind of traversal that is performed.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Iterator
*ConcreteIterator
*Aggregate
*ConcreteAggregate
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ Simplifies the interface of the Aggregate by not polluting it with traversal methods.
+ More than one traversal can be pending on an Aggregate.
+ Supports variant traversal techniques.

************************************************
COMPOSITE PATTERN:
Applicability:
You want to represent part-whole hierarchies of objects.
You want clients 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
*Leaf
*Composite
*Client
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ It makes it easy to add new kinds of components.
+ It makes clients simpler since they do not have to know if they are dealing with a leaf or a composite
component. Uniform treatment of composite and individual object.
+ Can make a design over general:
++ Smt we want a composite to have only certain components.
++ Need runtime checks.
--------------------------------------------------------------------------------------------------------------------------------------
Transparency: Gives us the illusion that component objects can be treated the same way.
Safety: Avoid cases where the client attemps to do sth meaningless, like adding components to Leaf objects.

************************************************
COMMAND PATTERN:
Applicability:
- You want to implement a callback function capability.
- You want to specify, queue, and execute requests at different times.
- You need to support undo and change log operations.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Command
*ConcreteCommand
*Client
*Invoker
*Receiver
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ Command decouples the object that invokes the operation from the one that knows how to perform it.
+ Commands are first-class objects. They can be manipulated and extended like any other object.
+ Commands can be made into a composite command (Macro command).
+ Commands provide a nice mechanism to package a piece of computation and pass it.

************************************************
ABSTRACT FACTORY PATTERN:
Class creational patterns focus on the use of inheritance to decide the object to be instantiated (Factory Method)
Object creational patterns focus on the delegation of the instantiation to another object (Abstract Factory)
--------------------------------------------------------------------------------------------------------------------------------------
Applicability:
- A system should be independent of how its products are created, composed, and represented.
- A class cannot anticipate the class of objects it must create.
- A system must use just one of a set of families of products.
- A family of related product objects is designed to be used together, and you need to enforce this constraint.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*AbstractFactory
*ConcreteFactory
*AbstractProduct
*ConcreteProduct
*Client
--------------------------------------------------------------------------------------------------------------------------------------
Abstract Factory (Object) vs. Factory (Class)
- Abstract Factory uses object composition to decouple applications from specific implementations.
- Abstract Factory provides more flexibility than Factory Method by delegating instantiation to another object
instead of changing subclass to be instantiated, but it is more complex than Factory Method as well.
- Abstract Factory creates a family of related products.
- Factory Method uses inheritance to decouple applications from specific implementations.
- Factory Method defines an interface for creating an object but lets the subclasses decide which class
instantiate.
- Factory Method lets a class defer instantiation to subclasses.
+ Both patterns are good at decoupling applications from specific implementations.
+ Both patterns create objects.
+ Both patterns encapsulate object creation.
+ Both patterns allow us to write methods that create new objects without explicitly using the new operator.
+ Both patterns are creational patterns which abstract the object instantiation process:
++ Hide how objects are created.
++ Make system independent of how its objects are created and composed.

************************************************
FACTORY PATTERN:
Applicability:
- A class cannot anticipate the class of objects it must create.
- A class wants its subclasses to specify the objects it creates.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Product
*ConcreteProduct
*Creator
*ConcreteCreator
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ Code is made more flexible and reusable by the elimination of instantiation of application-specific classes.
+ Factory methods eliminate the need to bind application-specific classes into your code.
+ Code deals only with the interface of the Product class and can work with any ConcreteProduct class that
supports this interface.
- Clients might have to subclass the Creator class just to instantiate a particular ConcreteProduct.

************************************************
FAÇADE PATTERN:
Applicability:
- To provide a simple interface to a complex subsystem. This interface is good enough for most clients; more
sophisticated clients can look beyond the façade.
- To decouple the classes of the subsystem from its clients and other subsystems thereby promoting subsystem
independence and portability.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Façade
*Subsystem classes
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ It hides the implementation of the subsystem from clients, making the subsystem easier to use.
+ It promotes weak coupling between the subsystem and its clients. This allows you to change the classes that
compromise the subsystem without affecting the clients.
+ It reduces compilation dependencies in large sw systems.
+ It simplifies porting systems to other platforms, bcs it’s less likely that building one subsystem requires
building all others.
+ It doesn’t prevent sophisticated clients from accessing the underlying classes.
+ Façade doesn’t add any functionality, it just simplifies interfaces.
- It does not prevent clients from accessing the underlying classes.

************************************************
SINGLETON PATTERN:
The singleton instance is only created when needed. This is called lazy instantiation. This code is also
guaranteed to be thread safe.
--------------------------------------------------------------------------------------------------------------------------------------
Applicability:
- There must be exactly one instance of a class. It must be accessible to clients from a well-known access point.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Singleton
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ Controlled access to sole instance.
+ Permits a variable number of instances.
************************************************
TEMPLATE PATTERN:
Applicability:
- To implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior
that can vary.
- To localize common behavior among subclasses and place it in a common class to avoid code duplication
(code refactoring).
- To control how subclasses extend superclass operations. You can define a template method that calls hook
operations at specific points, thereby permitting extensions only at those points.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*AbstractClass
*ConcreteClass

************************************************
ADAPTER PATTERN:
Applicability:
- You want to use an existing class, and its interface does not match the one you need.
- You want to create a reusable class that cooperates with unrelated classes with incompatible interfaces.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Target
*Adapter
*Client
*Adaptee
--------------------------------------------------------------------------------------------------------------------------------------
Object Adapters (composition) vs. Class Adapters (inheritance)
- With class adapter we subclass the Target and the Adaptee, while the object adapter uses composition to pass
requests to an adaptee.
- Class Adapter will not work when we adapt a class and its subclasses. Object Adapter will work with Adaptee
itself and with all its subclasses.
- Class Adapter can easily override Adaptee’s behavior since Adapter is subclass of Adaptee. This is harder to
do in Object Adapter. It requires subclassing the Adaptee and referring to the subclass in the Adapter.
- Class Adapter does not require pointer indirection to get to the Adaptee.
--------------------------------------------------------------------------------------------------------------------------------------
Façade vs. Adapter
- Adapter and Façade are both wrappers; but they are different kinds of wrappers.
- Façade defines a new interface, whereas Adapter uses an old interface.
- Adapter makes two existing interfaces work together as opposed to defining an entirely new one.
- Façade’s intent is to produce a simpler interface, and the intent of Adapter is to design to an existing interface.

************************************************
OBSERVER PATTERN:
Applicability:
- When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate
objects lets you vary and reuse them independently.
- When a change to one object requires changing others.
- When an object should be able to notify other objects without making assumptions about those objects.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Subject
*Observer
*ConcreteSubject
*ConcreteObserver
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ Minimal coupling between the Subject and the Observer:
++ Can reuse subjects without reusing their observers and vice versa.
++ Observers can be added without modifying the subject.
++ All subject knows is its list of observers.
++ Subject does not need to know the concrete class of and observer, just that each observer implements the
updated interface.
++ Subject and observer can belong to different abstraction layers.
+ Support for event broadcasting.
++ Subject sends a notification to all subscribed observers.
++ Observers can be added/removed at any time.
- Observers are not necessarily aware of each other and must be careful about triggering updates.
- Simple update interface requires observers to deduce changed item.

************************************************
VISITOR PATTERN:
Applicability:
- When many distinct and unrelated operations need to be performed on objects in an object structure, and you
want to avoid polluting their classes with these operations.
- When the classes defining the object structure rarely change, but you often to define new operations over the
structure.
- When an object structure contains many classes of objects with differing interfaces, and you want to perform
operations on these objects that depend on their concrete classes.
--------------------------------------------------------------------------------------------------------------------------------------
Double Dispatch:
- An accept method in the hierarchy welcomes visitors polymorphically.
- The accept method calls the visitors operation also polymorphically.
- So, the right combination of subject and visitor is invoked.
--------------------------------------------------------------------------------------------------------------------------------------
Participants:
*Visitor
*ConcreteVisitor
*Element
*ConcreteElement
*Object Structure
--------------------------------------------------------------------------------------------------------------------------------------
Consequences:
+ Adding new operations is easy.
+ Related behavior is not spread over the classes defining the object structure, it is localized in a visitor.
Unrelated sets of behavior are partitioned in their own visitor subclasses.
+ Visitors can accumulate state as they visit each element in the object structure. Without a visitor, this state
would have to be passed as extra arguments to the operations that perform the traversal.
- Adding new ConcreteElement classes is hard. Each new ConcreteElement gives rise to a new abstract
operation on Visitor and a corresponding implementation in every ConcreteVisitor class.
- The ConcreteElement interface must be powerful enough to let visitors do their job. You may be forced to
provide public operations that access an element’s internal state, which may compromise its encapsulation.