Austin Morris [email protected] austinsmorris An Introduction to Design Patterns 

(1977) In the beginning... 

No content

(1995) Let there be light… 

No content

What is a design pattern? 

1.) Repeated problem What is a design pattern? 

1.) Repeated problem 2.) Reusable solution What is a design pattern? 

1.) Repeated problem 2.) Reusable solution 3.) Name What is a design pattern? 

1.) Repeated problem 2.) Reusable solution 3.) Name 4.) Set of consequences What is a design pattern? 

Why do we use design patterns? 

Because the one constant in software development is change. Why do we use design patterns? 

Because somebody has already solved your problem. Why do we use design patterns? 

Because you don’t remember that thing you did that one time when the other stuff didn’t work. Why do we use design patterns? 

Because we have to make trade-offs. Why do we use design patterns? 

What are the design patterns? 

GOF published 23 “original” design patterns. Then: 

● Abstract Factory ● Builder ● Factory Method ● Prototype ● Singleton ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento ● Observer ● State ● Strategy ● Template Method ● Visitor 

(All the design patterns I could find in ten minutes plus the time it took to type them.) Now: 

Abstract Client, Abstract Factory, Abstract Server, Action, Active Object, Active Record, Adapter, Application Controller, Association Table Mapping, Balking, Binding Properties, Bridge, Builder, Caretaker, Chain Of Responsibility, Class Table Inheritance, Client Session State, Coarse-Grained Lock, Concrete Table Inheritance, Command, Composite, Cursor, Data Bus, Data Mapper, Data Transfer Object, Database Session State, Decorator, Dependent Mapping, Dependents, Disable Job Request While Running Job, Domain Model, Double Checked Locking, Dynamic User Interface, Embedded Value, Event Based Asynchronous, Facade, Facet, Factory Method, Flyweight, Foreign Key Mapping, Front Controller, Gateway, Guarded Suspension, Handle Body, Hierarchical Visitor, Identity Field, Identity Map, Implicit Lock, Inheritance Mappers, Interface Segregation Principle, Interpreter, Iterator, Join, Kit, Layer Supertype, Lazy Instantiation, Lazy Load, Lock, Mapper, Mediator, Memento, Messaging, Metadata Mapping, Mock Object, Model View Controller, Module, Money, Monitor, Monostate, Multiton, Null Object, Object Pool, Observer, Optimistic Offline Lock, Page Controller, Pessimistic Offline Lock, Plugin, Policy, Prototype, Proxy, Publish Subscribe, Pub Sub, Query Object, Reactor, Read Write Lock, Record Set, Registry, Remote Facade, Repository, Resource Acquisition is Initialization, Row Data Gateway, Scheduled Task, Scheduler, Separated Interface, Serialized Large Object, Server Session State, Servant, Service Layer, Service Locator, Service Stub, Single Table Inheritance, Singleton, Special Case, Specification, State, States, Static User Interface, Strategy, Surrogate, Table Data Gateway, Table Module, Template Method, Template View, Thread Pool, Thread Specific Storage, Token, Transaction, Transaction Script, Transfold, Transform View, Translator, Two Step View, Unit of Work, Value Object, Virtual Constructor, Visitor, Wrapper 

“Original” Design Pattern Categories 

“... abstract the instantiation process... make a system independent of how its objects are created, composed, and represented.” Creational 

● Abstract Factory ● Builder ● Factory Method ● Prototype ● Singleton ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento ● Observer ● State ● Strategy ● Template Method ● Visitor 

“...concerned with how classes and objects are composed to form larger structures.” Structural 

● Abstract Factory ● Builder ● Factory Method ● Prototype ● Singleton ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento ● Observer ● State ● Strategy ● Template Method ● Visitor 

“...concerned with algorithms and the assignment of responsibility between objects… shift focus of flow of control to the way objects are interconnected.” Behavioral 

● Abstract Factory ● Builder ● Factory Method ● Prototype ● Singleton ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento ● Observer ● State ● Strategy ● Template Method ● Visitor 

Design patterns are not: 

Invented. 

Invented. Design patterns are discovered through repeated application to generic problems. 

Design patterns are not: 

The end goal. 

They are the means to an end. The end goal. 

Design patterns are not: 

Design principles. 

Design patterns allow you to apply good design principles. Design principles. 

In this case, interface means abstraction. “Program to an interface, not an implementation.” 

Abstract Factory - use an interface to create objects. The type is determined at runtime. “Program to an interface, not an implementation.” 

Adapter - convert an existing interface into one that a client expects. “Program to an interface, not an implementation.” 

Template Method - Define a skeleton algorithm that subclasses implement. “Program to an interface, not an implementation.” 

Has-a is “better” than Is-a. “Favor object composition over class inheritance.” 

Composite - has objects in a hierarchy. “Favor object composition over class inheritance.” 

Strategy - an object has a variable behavior. “Favor object composition over class inheritance.” 

Iterator - has objects that it iterates through. “Favor object composition over class inheritance.” 

Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle. Interface Segregation Principle Dependency Inversion Principle S.O.L.I.D. 

Abstract Client, Abstract Factory, Abstract Server, Action, Active Object, Active Record, Adapter, Application Controller, Association Table Mapping, Balking, Binding Properties, Bridge, Builder, Caretaker, Chain Of Responsibility, Class Table Inheritance, Client Session State, Coarse-Grained Lock, Concrete Table Inheritance, Command, Composite, Cursor, Data Bus, Data Mapper, Data Transfer Object, Database Session State, Decorator, Dependent Mapping, Dependents, Disable Job Request While Running Job, Domain Model, Double Checked Locking, Dynamic User Interface, Embedded Value, Event Based Asynchronous, Facade, Facet, Factory Method, Flyweight, Foreign Key Mapping, Front Controller, Gateway, Guarded Suspension, Handle Body, Hierarchical Visitor, Identity Field, Identity Map, Implicit Lock, Inheritance Mappers, Interface Segregation Principle, Interpreter, Iterator, Join, Kit, Layer Supertype, Lazy Instantiation, Lazy Load, Lock, Mapper, Mediator, Memento, Messaging, Metadata Mapping, Mock Object, Model View Controller, Module, Money, Monitor, Monostate, Multiton, Null Object, Object Pool, Observer, Optimistic Offline Lock, Page Controller, Pessimistic Offline Lock, Plugin, Policy, Prototype, Proxy, Publish Subscribe, Pub Sub, Query Object, Reactor, Read Write Lock, Record Set, Registry, Remote Facade, Repository, Resource Acquisition is Initialization, Row Data Gateway, Scheduled Task, Scheduler, Separated Interface, Serialized Large Object, Server Session State, Servant, Service Layer, Service Locator, Service Stub, Single Table Inheritance, Singleton, Special Case, Specification, State, States, Static User Interface, Strategy, Surrogate, Table Data Gateway, Table Module, Template Method, Template View, Thread Pool, Thread Specific Storage, Token, Transaction, Transaction Script, Transfold, Transform View, Translator, Two Step View, Unit of Work, Value Object, Virtual Constructor, Visitor, Wrapper 

How can I learn more? 

How can I learn more? 1.) Collect buzzwords. 

How can I learn more? 1.) Collect buzzwords. 2.) Connect buzzwords. 

How can I learn more? 1.) Collect buzzwords. 2.) Connect buzzwords. 3.) Write code. 

Recommended Reading 

No content

Austin’s Opinion: Mandatory reference for anybody who wants to incorporate design patterns in their software. 

No content

Austin’s Opinion: Mandatory reading for anybody who wants to write great software. Talks about patterns for domain modeling. 

No content

Austin’s Opinion: Optional reading - If you are already using a good framework/ORM, you are already using most of these patterns. 

No content

Austin’s Opinion: A great, easy-reading alternative to textbook-style books. Recommended by original GOF authors. 

Questions? [email protected]