View on GitHub

Just making some notes as I attempt to work through this book and start using recognised Design Patterns.


A family of algorithmns.



The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and update automatically.


The Decorator Pattern

Decorate your classes at runtime using a form of object composition.

Example is zillion types of Starbucks all * with * different additions ** EspressoWithSteamedMilkandMocha **.

Identify areas which may change.

  1. Take a DarkRoast object
  2. Decorate it with a Mocha object
  3. Decorate it with a Whip

Decorators implement the same interface as the component they are going to decorate. Pg 95 the Decorator extends the Beverage class.


This is how you use it:

  drink = new Darkroast();
  drink = new Mocha(Drink);
  drink = new Whip(Drink);

The Factory Pattern

new - think when newing, is this better in a Factory?

Identify the aspects that vary and separate them from what stays the same. ** An object that just creates objects, other objects use this, when they need new objects = Factory. **

pizza = factory.createPizza(type);

Simple Factory


Got the simplw one working OK.

Tie the store and the factory together.

** Come back to this ** Pg - 139.

The Singleton Pattern

The PHP Way:

// General singleton class.
class Singleton {
  // Hold the class instance.
  private static $instance = null;
  // The constructor is private
  // to prevent initiation with outer code.
  private function __construct()
    // The expensive process (e.g.,db connection) goes here.
  // The object is created from within the class itself
  // only if the class has no instance.
  public static function getInstance()
    if (self::$instance == null)
      self::$instance = new Singleton();
    return self::$instance;

The Command Pattern - Encapsulating Invocation

Remote control analogy. Lots of classes with different interfaces. Command object sits in the middle and decouples.

** Read over this chapter again **


Travel plug analogy.

Make an adapter so that a Turkey can be used like a Duck.

public class TurkeyAdapter implemements Duck{
  Turkey turkey;

  public TurkeyAdapter(Turkey turkey){
    this.turkey = turkey;
  public void quack() {

  public void fly() {



Basically just create an adapter class which sits between a client and adaptee and translates the requests.

Facade Pattern

Analogy home theatre, lots of tasks to watch a film. Facade Pattern takes a complex system and makes it easier by implementing a Facade class that provides one, more reasonable interface.

Facade will just have one method (watchMovie) which triggers all the sub tasks.

** A Simplified Interface **

The Principle of Least Knowledge

“talk only to your immediate friends”

From a method in an object you can only invole methods which belong to:

1, The object itself 2, Objects passed in as a parameter to the method 3, Any object the method creates or instantiates 4, Any components of the object

Encapsulating Algorithmns - The Template Method Pattern

Brewing tea and coffee example.

CaffeineBeverage contains boilWater() and pourInCup(). Tea and Coffee extend and code for brew and add condiments is in them.

** The Template Method Pattern ** Defines the skeleton of an alogrithm in a method, deferring some steps to subclasses. Subclasses can alos redifine certain steps.

** The Hollywood Principle **

Prevents dependency rot - high level components depending on low level components.

With the Hollywood Principle we allow low-level components to hook themselves into a system. High-level components say “don’t call us, we’ll call you”.

In the tea/coffee example, the Caffeine Beverage class calls Tea and Coffee, not the other way around.

Well-Managed Collections - The Interior and Composite Patterns

The Iterator Pattern

The Composite Pattern

The State Pattern

State implements the behaviours that are appropriate for that state.

The class that uses these has a ** current state ** and when it calls the methods, the correct code for the current state is executed.

The Proxy Pattern

Proxies control and manage access. They stand in for the objects they are protecting.

Patterns in the Real World


** Look up, how to choose a design pattern. **

** Watch the Laracast again **

Single Responsibility (S in SOLLID)

A class should have only one reason to change.

OO Principles

Encapsulate what varies Favor composition over inheritance Program to interfaces not implementations Strive for loosely coupled designs between objects that interact

** Code should be closed to to change, open to extension **

Design Principle

Identify the aspects of your application that vary and separate them from what stays the same.