Design Patterns (gang-of-four)
Creational Patterns
Abstract Factory
(87) Provide an interface for creating families of
related or dependent objects without specifying their concrete classes.
Builder
(97) Separate the construction of a complex object from its
representation so that the same construction process can create different
representations.
Factory Method
(107) Define an interface for creating an object, but let
subclasses decide which class to instantiate. Factory Method lets a class defer
instantiation to subclasses.
Prototype
(117) Specify the kinds of objects to create using a
prototypical instance, and create new objects by copying this prototype.
Singleton
(127) Ensure a class only has one instance, and provide a
global point of access to it.
Structural Patterns
Adapter
(139) Convert the interface of a class into another interface
clients expect. Adapter lets classes work together that couldn't otherwise
because of incompatible interfaces.
Bridge
(151) Decouple an abstraction from its implementation so that the
two can vary independently.
Composite
(163) Compose objects into tree structures to represent
part-whole hierarchies. Composite lets clients treat individual objects and
compositions of objects uniformly.
Decorator
(175) Attach additional responsibilities to an object
dynamically. Decorators provide a flexible alternative to subclassing for
extending functionality.
Facade
(185) Provide a unified interface to a set of interfaces in a
subsystem. Facade defines a higher-level interface that makes the subsystem
easier to use.
Flyweight
(195) Use sharing to support large numbers of fine-grained
objects efficiently.
Proxy
(207) Provide a surrogate or placeholder for another object to
control access to it.
Behavioral Patterns
Chain of Responsibility
(223) Avoid coupling the sender of a request to
its receiver by giving more than one object a chance to handle the request.
Chain the receiving objects and pass the request along the chain until an
object handles it.
Command
(233) Encapsulate a request as an object, thereby letting you
parameterize clients with different requests, queue or log requests, and
support undoable operations.
Interpreter
(243) Given a language, define a represention for its
grammar along with an interpreter that uses the representation to interpret
sentences in the language.
Iterator
(257) Provide a way to access the elements of an aggregate
object sequentially without exposing its underlying representation.
Mediator
(273) Define an object that encapsulates how a set of objects
interact. Mediator promotes loose coupling by keeping objects from referring to
each other explicitly, and it lets you vary their interaction independently.
Memento
(283) Without violating encapsulation, capture and externalize
an object's internal state so that the object can be restored to this state
later.
Observer
(293) Define a one-to-many dependency between objects so that
when one object changes state, all its dependents are notified and updated
automatically.
State
(305) Allow an object to alter its behavior when its internal
state changes. The object will appear to change its class.
Strategy
(315) Define a family of algorithms, encapsulate each one, and
make them interchangeable. Strategy lets the algorithm vary independently from
clients that use it.
Template Method
(325) Define the skeleton of an algorithm in an
operation, deferring some steps to subclasses. Template Method lets subclasses
redefine certain steps of an algorithm without changing the algorithm's
structure.
Visitor
(331) Represent an operation to be performed on the elements of
an object structure. Visitor lets you define a new operation without changing
the classes of the elements on which it operates.
Head First Design Patterns
|
Our focus is on the core patterns that matter from the original GoF patterns,
and making sure that you really, truly, deeply understand how and when to use
them. You will find a brief look at some of the other patterns (the ones
you're far less likely to use) in the appendix.
|
| |
The GoF patterns discussed in detail:
- Strategy (p24)
- Observer (p44)
- Decorator (p88)
- Factory Method (p131)
- Abstact Factory (p153)
- Singleton (p171)
- Command (p201)
- Adapter (p241)
- Facade (p264)
- Template Method (p286)
- Iterator (p325)
- Composite (p356)
- State (p410)
- Proxy (p460)
The GoF patterns briefly introduced:
- Bridge (p612)
- Builder (p614)
- Chain of Reponsibility (p616)
- Flyweight (p618)
- Interpreter (p620)
- Mediator (p622)
- Memento (p624)
- Prototype (p626)
- Visitor (p628)
Design Principles
- Encapsulate what varies (p9)
- Program to interfaces, not implementations (p11)
- Favor composition over inheritance (p23)
- Strive for loosely coupled designs between objects that interact (p53)
- Classes should be open for extension but closed for modification (p86)
- Depend on abstractions. Do not depend on concrete classes. (p139)
- Principle of Least Knowledge - talk only to your immediate friends (p265)
- The Hollywood Principle - don't call us, we'll call you (p296)
- A class should have only one reason to change (p339)
Sample chapter: Decorator
pattern
Poster Web page
Book's Web page
Publisher's Web page
Design Patterns Explained
A customer review @ Amazon ... "I picked up this book after reading through the
original GoF Design Patterns. Although they discuss similar topics and this
book refers to the GoF book quite frequently, I wouldn't necessarily associate
the two with each other despite having similiar book titles. There isn't much
code or elaborate examples in this book, but it is easily read and understood
by any level of programmer. In my opinion though you should probably read this
book first before you read the GoF book despite this one actually being the one
that is supposed to explain the other. To me it felt more like a synopsis and
is too brief in many places. More or less it makes a good introduction into
design patterns, but it is not the book that will give you a full understanding
of patterns."
The authors do not introduce all 23 GoF patterns. Those discussed are:
- Abstract Factory
- Factory Method
- Singleton
- Adapter
- Bridge
- Facade
- Decorator
- Observer
- Strategy
- Template Method
UML and GRASP Patterns
|
The critical design tool for software development is a mind well educated
in design principles. It is not the UML or any other technology. — Craig Larman
|
| |
GRASP (General Responsibility Assignment Software Patterns) are
guidelines for assigning responsibility to classes and objects in OO design.
They are really a mental toolset, a learning aid to help in the design of
object oriented software. The patterns and principles specified by GRASP are ...
- Information Expert
- Look at a given responsibility, determine the information needed to fulfill
it, and then determine where that information is stored. Information Expert
will lead to placing the responsibility on the class with the most information
required to fulfill it.
- Creator
- Creation of objects is one of the most common activities in an
object-oriented system. Which class is responsible for creating objects is a
fundamental property of the relationship between objects of particular classes.
In general, a class B should be responsible for creating instances of class A
if one, or preferably more, of the following apply:
- Instances of B contains or compositely aggregates instances of A
- Instances of B record instances of A
- Instances of B closely use instances of A
- Instances of B have the initializing information for instances of A and pass it on creation.
- Controller
- Assign the responsibility of dealing with system events to a non-UI class
that represents the overall system or a use case scenario. A Controller object
is a non-user interface object responsible for receiving or handling a system
event. It should delegate to other objects the work that needs to be done; it
coordinates or controls the activity. It should not do much work itself.
- Low Coupling
- Refers to the degree of direct knowledge that one class has of another.
This supports: low dependency between classes, low impact in a class due to
changes in other classes, and high reuse potential.
- High Cohesion
- Keep objects appropriately focused, manageable and understandable. High
cohesion is generally used in support of Low Coupling. High cohesion means that
the responsibilities of a given element are strongly related and highly
focused. Breaking programs into classes and subsystems is an example of
activities that increase the cohesive properties of a system. Alternatively,
low cohesion is a situation in which a given element has too many unrelated
responsibilities. Elements with low cohesion often suffer from being hard to
comprehend, hard to reuse, hard to maintain and adverse to change.
- Polymorphism
- Promote common interface to a base class, and bury peculiar implementation
details in derived classes. The client of the abstraction hierarchy should
then couple itself only to the base class. Another way this has been descirbed
is: the responsibility of defining the variation of behaviors based on type is
assigned to the types for which this variation happens.
- Pure Fabrication
- Invent a class that does not represent a concept in the problem domain.
It is conceived to achieve low coupling, high cohesion, and reuse potential
across the classes that represent domain concepts.
- Indirection
- Assign the responsibility of mediation between two elements to an
intermediate object. An example of this is the introduction of a controller
component for mediation between data (model) and its representation (view) in
the Model-View-Controller pattern.
- Protected Variations
- Protect elements from the variations on other elements (objects, systems,
subsystems) by wrapping the focus of instability with an interface and using
polymorphism to create various implementations of this interface.