Assumptions and Disclaimers

• UML and code samples from https://github.com/domnikl/DesignPatternsPHP
• This is only an introduction
• We only have about 45 minutes

Outline

• Common Language
• SOLID and DRY
• Common Patterns
• Questions

Common Language

• In the world of software, a pattern is a tangible manifestation of an organization’s tribal memory. —Grady Booch in Core J2EE Patterns
• [A pattern is] a solution to a problem in a context. —The Gang of Four, Design Patterns: Elements of Reusable Object-Oriented Software

• Language independent
• Define a problem
• Define a solution
• Provide a common language for collaborating

Three Basic Types

• Structural
• Behavioral
• Creational

SOLID & DRY

S - Single Responsibility Principle

A class should have one and only one responsibility.

use Illuminate\Support\ServiceProvider;

class EventServiceProvider extends ServiceProvider {

    public function register() {
        $this->app['events'] = $this->app->share(function($app) {
            return new Dispatcher($app);
        });
    }
}

O - Open/Closed Principle

A class should be open for extension, but closed for modification.

use Stanley\Example\PartInterface;
use Illuminate\Support\Collection;

public function getTotal(Collection $parts) {
    return $parts->reduce(function(PartInterface $part) {
        return $part->getPrice();
    });
}

L - Liskov Substitution Principle

Objects should replaceable with instances of their subtypes.

abstract class Exam {
    abstract public function score();
}

class Quiz extends Exam {
    public function score() {
        return "100";
    }
}

class Grade {
    protected $scores;
    public function calculate(Exam $exam) {
        $this->scores += $exam->score();
    }
} 

I - Interface Segregation

A client should not be forced to implement methods that it doesn't use.

D - Dependency Inversion

Abstractions should not depend upon details. Details should depend upon abstractions.

DRY

• Don't Repeat Yourself

Examples

• Singleton
• Observer
• Factory Method
• Dependency Injection

Singleton

Singleton - The Problem

• Sometimes, we think we need near-global access to an object or a set of values without using global variables.
• Further, sometimes we need to ensure that all parts of our application use one, and only one, instance of a class.

Singleton - The Implementation

Singleton - Consequences

• Can make it tougher to test
• Can make it tougher to debug
• Easy to over-use

Observer

Observer - The Problem

• Business rules dictate that when a certain value changes or the system completes a specific action, then multiple other actions must occur.
• When new user registers, start a session, write data to db, send welcome email, create s3 bucket, etc.
• Just before a model is updated, write the old row data to an audit table.

Observer - The Implementation

Observer - Benefits

• Promotes loose coupling of components
• Can add/remove listeners very easily
• In this example, concrete objects depend upon abstractions, satisfying the Dependency Inversion principle

Factory Method

Factory Method - The Problem

• Object creation is a pain.
• Sometimes, we don't know what type of object we need until run-time

Factory Method - The Implementation

Factory Method - Benefits

• We've removed object creation to a specialized class
• Grouping the creation of similar objects into a single process promotes code re-use
• In this example, concrete objects depend upon abstractions, satisfying the Dependency Inversion principle

Dependency Injection

Dependency Injection - The Problem

• Configuration values (db user, db password, etc) are often needed within classes

Dependency Injection - The Implementation

Dependency Injection - Benefits

• Improves testability
• Improves clarity of code
• For me, forces me to think about what the class is doing