GoF Design Patterns The underlying principles of GoF Patterns GoF Design Principles

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