Head First Design Patterns

Concepts
1. Change is constant in software development.
2. No matter how well you design an application, over time an application must grow and
change or it will die.
3. Design principle: Identify the aspects of your application that vary and separate them
from what stays the same.
4. If you have got some aspect of your code that is changing, say with every new
requirement, then you know you have got a behaviour that needs to be pulled out and
separated from all the stuff that does not change.
5. Take the parts that vary and encapsulate them, so that later you can alter or extend the
parts that vary without affecting those that don’t.
6. This simple concept forms the basis for almost every design pattern. All patterns
provide a way to let some part of a system vary independently of all other parts.
7. Take what varies and encapsulate it so it won’t affect the rest of your code. The result is
fewer unintended consequences from code changes and more flexibility in your systems.
8. Design principle: Program to an interface, not an implementation.
9. Design principle: Favour composition over inheritance.
10. Creating systems using composition gives lot more flexibility. Not only does it let you
encapsulate a family of algorithms (or behaviours) into their own set of classes, but it also
lets you change behaviour at runtime as long as the object you are composing with
implements the correct behaviour interface.
11. Design patterns tell us how to structure classes and objects to solve certain problems and
it is our job to adapt those designs to fit our particular application.
12. Frameworks and libraries are not design patterns; they provide specific implementations
that we link into our code. Sometimes, however, libraries and frameworks make use of
design patterns in their implementations.
13. Object oriented principles:
- Encapsulate that varies
- Favour composition over inheritance
- Program to interfaces, not implementations
- Strive for loosely coupled designs between objects that interact
14. Most patterns and principles address the issues of change in software.
15. Most patterns allow some part of a system to vary independently of all other parts.
16. We often try to take what varies in a system and encapsulate it.
17.

The strategy pattern

1. The strategy pattern defines a family of algorithms, encapsulates each one, and makes
them interchangeable. Strategy lets the algorithm vary independently from clients that
use it.
The Observer Pattern
1. The observer pattern is one of the most widely used patterns in the JDK.
2. This pattern keeps your objects in the know when something they might care about
happens. Objects can even decide at runtime whether they want to be kept informed.
3. Pub-Sub: Publishers + Subscribers = Observer pattern. Publisher is the Subject and
subscribers are the observers.
4. Subject object manages some bit of data.
5. When data in the subject changes, the observers are notified.
6. The observers have subscribed to (registered with) the subject to receive updates when
the subject’s data changes.
7. New data values are communicated to the observers in some form when they change.
8. The observer pattern defines a one-to-many dependency between objects so that when
one object changes state, all of its dependants are notified and updated automatically.
9. When two objects are loosely coupled, they can interact, but have very little knowledge
of each other.
10. Definition: The observer pattern provides an object design where subjects and observers
are loosely coupled.
11. Design Principle: Strive for loosely coupled designs between objects that interact.
12. Loosely coupled designs allow us to build flexible OO systems that can handle change
because they minimize the interdependency between objects.
13. Java has built in support for observer pattern in several of its APIs. The most general is
the Observer interface and the Observable class in the [Link] package.
14. The [Link] implementation of Observer/Observable is not the only place you will find
the observer pattern in the JDK; both JavaBeans and Swing also provide their own
implementations of the pattern.
15. The thing that varies in the observer pattern is the state of the subject and the number and
types of observers. With this pattern, you can vary the objects that are dependant of the
state of the subject, without having to change that subject.

The decorator pattern

1. Once you know the techniques of decorating, you will be able to give your objects new
responsibilities without making any code changes to the underlying classes.
2. Decorators have the same supertype as the objects they decorate.
3. You can use one or more decorators to wrap an object.
4. Given that the decorator has the same supertype as the object it decorates, we can pass
around a decorated object in place of the original (wrapped) object.
5. The decorator adds its own behaviour either before and/or after delegating to the object
it decorates to do the rest of the job.
6. Objects can be decorated at any time, so we can decorate objects dynamically at runtime
with as many decorators as we like.
7. Definition: The decorator pattern attaches additional responsibilities to an object
dynamically. Decorators provides a flexible alternative to subclassing for extending
functionality.

The key point is that it’s vital that the decorators have the same type as the objects they
are going to decorate. So here we’re using inheritance to achieve the type matching, but
we aren’t using inheritance to get behaviour.
8. When we compose a decorator with a component, we are adding new behavior. We are
acquiring new behaviour not by inheriting it from a superclass, but by composing objects
together.
9. That means we’re subclassing the abstract class in order to have the correct type, not to
inherit its behaviour. The behaviour comes in through the composition of decorators with
the base components as well as other decorators
10. Decorating the [Link] class

11. Java I/O also points out one of the downsides of the Decorator Patter: designs using this
pattern often result in a large number of small classes that can be overwhelming to a
developer tr ying to use the Decorator-based API.
12. C++ example
 Widget* aWidget = new BorderDecorator(
new HorizontalScrollBarDecorator(
new VerticalScrollBarDecorator(
new Window( 80, 24 ))));
aWidget->draw();

13. The Decorator Pattern provides an alternative to sub classing for extending behaviour.
14. The Decorator Pattern involves a set of decorator classes that are used to wrap concrete
components.
15. Decorator classes mirror the type of the components they decorate. (In fact, they are the
same type as the components they decorate, either through inheritance or interface
implementation.)
16. Decorators change the behaviour of their components by adding new functionality before
and/or after (or even in place of) method calls to the component.
17. You can wrap a component with any number of decorators.
18. Decorators are typically transparent to the client of the component; that is, unless the
client is relying on the component’s concrete type.
19. Decorators can result in many small objects in our design, and overuse can be complex

Open Closed Principle

1. Classes should be open for extension, but closed modification.
2. The goal is to allow classes to be easily extended to incorporate new behaviour without
modifying existing code. What do we get if we accomplish this? Designs that are resilient
to change and flexible enough to take on new functionality to meet changing
requirements.
3. While it may seem like a contradiction, there are techniques for allowing code to be
extended without direct modification.
4. Be carefuk when choosing the areas of code that need to be extended: applying the open-
closed principle everywhere is wasteful, unnecessary and can lead to complex, hard to
understand code.
5. While inheriting is powerful, it does not always lead to the most flexible or maintainable
designs. There are ways of inheriting behaviour at runtime through composition and
delegation.
6. When inheriting the behaviour by sub classing, that behaviour is set statically at compile
time. In addition, all subclasses must inherit the same behaviour. If however, an object’s
behaviour is extended through composition, then this can be done this dynamically at
runtime.
7. It is possible to add multiple new responsibilities to objects through this technique,
including responsibilities that were not even thought of by the designer of the superclass.
And, that too without touching their code.
8. By dynamically composing objects, new functionality can be added by writing new code
rather than altering existing code. Because the existing code is not changed, the chances
of introducing bugs or causing unintended side effects in pre-existing code are much
reduced.

The factory Pattern

1. Factories handle the details of object creation.
2. The simple factory is not actually a design pattern; it is more of a programming idiom.
3. A factory method handles object creation and encapsulates it in a subclass. This
decouples the client code in the superclass from the object creation code in the subclass.
4. A factory method may be parameterised (or not) to select among several variations of a
product.
5. A factory method returns a product that is typically used within methods defined in the
superclass.
6. All factory patterns encapsulate object creation. The factory method pattern
encapsulates object creation by letting subclasses decide what objects to create.
7. The factory method pattern defines an interface for creating an object, but lets
subclasses decide which class to instantiate. Factory method lets a class defer
instantiation to subclasses.
8. We implemented what is known as the parameterised factory method. It can make more
than one object based on a parameter passed in. Often, however, a factory just produces
one object and is not parameterised. Both are valid forms of the pattern.
9. By placing all object creation code in one object or method, duplication of code is
avoided. This also means that clients depend only upon interfaces rather than the concrete
classes required to instantiate objects. This allows to program to an interface, not an
implementation, and that makes the code more flexible and extensible in the future.
10. Dependency inversion principle: Depend upon abstractions. Do not depend upon
concrete classes
a. No variable should hold a reference to a concrete class
b. No class should derive from a concrete class
c. No method should override an implemented method of any of its base classes
11. Page 155
12.

Design principles
1. Design principle 1: Identify the aspects of your application that vary and separate them
from what stays the same. (Encapsulate that varies_
2. Design principle 2: Program to an interface, not an implementation.
3. Design principle 3: Favour composition over inheritance.
4. Design Principle 4: Strive for loosely coupled designs between objects that interact.
5. Design Principle 5: Classes should be open for extension but closed for modification.
6. Design principle 6: Dependency inversion principle: Depend upon abstractions. Do not
depend upon concrete classes.
7.
8.

[Link]