GoF Design Patterns GoF Design Principles Overview of patterns Pattern Categorizations The underlying principles of GoF Patterns • Empasis on flexibility and reuse through decoupling of classes • The underlying principles 1) program to an interface, not to an implementation 2) favor composition over class inheritance 3) find what varies and encapsulate it 1 Class vs. Interface Inheritance • Class – defines an implementation • Type – defines only the interface – the set of requests that an object can respond to • Relation between Class and Type – the class of an object implies the type, not vice versa. • Class Inheritance – one implementation in terms of another – motivation: localization and reuse of code • Type Inheritance – when an object can be used in place of another – motivation: reducing dependencies, reusability, adaptability GoF Design Principle no. 1 Program to an interface, not an implementation • Use interfaces to define common interfaces – and/or abstract classes in C++ • Declare variables to be instances of the abstract class – not instances of particular classes • Use Creational patterns – to associate interfaces with implementations – protects the module responsible for creating concrete objects from depending on concrete classes Benefits Greatly reduces the implementation dependencies Client objects remain unaware of the classes that implement the objects they use. Clients know only about the abstract classes (or interfaces) that define the interface. 2 Class Inheritance vs. Composition • Mechanisms of reuse – White-box (inheritance) vs. Black-box (Composition) • Class Inheritance – easy to use; easy to modify • implementation being reused; – static bound ⇒ can't change at run-time; – mixture of physical data representation ⇒ breaks encapsulation • change in parent ⇒ change in subclass • change in subclass ⇒ change in inherited parent behavior • Object Composition – objects are accessed solely through their (well defined) service interfaces • no break of encapsulation – any object can be replaced by another at runtime • as long as they are the same type • as long as they conform to same contract (semantics) GoF Design Principle no. 2 Favor composition over class inheritance • Keeps classes focused on one task – high cohesion • A design favoring composition tends to have more objects, and the system’s behavior is depend on their interralations (instead of being defined in one class) • However, designs become more reusable by depending more on object composition •There is a clear tendency to rely too much on class inheritance. 3 The GoF Patterns Divided into three separate types • • • Creational patterns – Deal with initializing and configuring classes and objects Structural patterns – Deal with decoupling interface and implementation of classes and objects Behavioral patterns – Deal with dynamic interactions among societes of classes and objects Purpose Creational Structural Behavioral Class • Factory Method • Adapter • Interperter Object • Abstract Factory • Builder • Prototype • Singleton • • • • • • • • • Scope • • • • • • • Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Momento Observer State Strategy Vistor Creational • Factory Method – Define an interface for creating an object, but let the subclasses decide which class to instantiate. • Abstract Factory – Factory for building related objects without specifying their concrete classes. • Builder – Factory for building complex objects incrementally. Separates the construction of an object from its representation. • Prototype – Factory for cloning new instances from a prototype object. • Singleton – Factory for singular (sole) instances of a class. 4 Structural • Adapter – Convert an interface of a class into an other that the clients expect. • Bridge – Bind one of many implementations to one of many abstractions. • Composite – Structure for building recursive aggrecations • Decorator – Extending an object transparently by attaching additional responsibilities to it dynamically. Structural • Facade – Provide a unified and simplyfied interface to a set of interfaces in a subsystem. • Flyweight – Many fine-grained objects shared efficiently • Proxy – One object is used in place of another to control acces to it in some manner. 5 Behavioral • Chain of Responsibility – Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. • Command – Encapsulate a request as an object, and thereby parameterize clients with different requests. • Interpreter – Lanquage interpreter for a small grammar • Iterator – Aggregate elements are accessed sequentally • Mediator – Coordinates interactions between its associates. Defines and object that encapsulates how a set of its associates interact. Behavioral • Memento – Snapshot captures and stores object states without violating encapsulation. • Observer – Dependents update automatically when subject changes. • State – Object whose behavior depends on its state • Strategy – Abstraction for selecting one of many algorithms dynamically and transparently to clients. • Template Method – Lets subclasses redefine certain steps of an algorithm without changing the algorithm’s strucutre. • Visitor – Operations applied to elements of an heterogeneous object structure. Lets you define a new operation without changing the classes of the elements on which it operates. 6 Another categorization Creational Interface Structural Adapter Bridge Composite Facade Responsibility Singleton Construction Abstract Factory Builder Factory Method Prototype Flyweight Proxy Chain of Responsibility Mediator Observer Memento Operation Extension Behavioral Command Interpreter State Strategy Template Method Decorator Iterator Visitor 7