GoF Design Patterns The underlying principles of GoF Patterns GoF Design Principles
GoF Design Patterns
GoF Design Principles
Overview of patterns
The underlying principles of GoF
• Empasis on flexibility and reuse through decoupling of
• 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
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
Greatly reduces the implementation dependencies
objects remain unaware of the classes that implement the
objects they use.
know only about the abstract classes (or interfaces) that
define the interface.
Class Inheritance vs.
• 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
•There is a clear tendency to rely too much on class inheritance.
The GoF Patterns
Divided into three separate types
– Deal with initializing and configuring classes and objects
– Deal with decoupling interface and implementation of classes
– Deal with dynamic interactions among societes of classes and
• Factory Method • Adapter
Chain of Responsibility
• 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
– Factory for building complex objects incrementally.
Separates the construction of an object from its
– Factory for cloning new instances from a prototype object.
– Factory for singular (sole) instances of a class.
– Convert an interface of a class into an other that the clients
– Bind one of many implementations to one of many
– Structure for building recursive aggrecations
– Extending an object transparently by attaching additional
responsibilities to it dynamically.
– Provide a unified and simplyfied interface to a set of
interfaces in a subsystem.
– Many fine-grained objects shared efficiently
– One object is used in place of another to control acces to it
in some manner.
• 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.
– Encapsulate a request as an object, and thereby
parameterize clients with different requests.
– Lanquage interpreter for a small grammar
– Aggregate elements are accessed sequentally
– Coordinates interactions between its associates. Defines
and object that encapsulates how a set of its associates
– Snapshot captures and stores object states without violating
– Dependents update automatically when subject changes.
– Object whose behavior depends on its state
– 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.
– 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.
Chain of Responsibility