Power of PatternsOR

More Than Programming with Objects

Intro to Design PatternsMike Clement@mdclement

mike@softwareontheside.comhttp://blog.softwareontheside.com

Utah Code Camp Fall 2011

Design Patterns Defined

• Alexander’s Architecture Design Patterns

• Published in 1977

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to the problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

-Christopher Alexander

A Pattern is a solution to a problem in a context

• Context – recurring situation• Problem – goal and constraints• Solution – general design to resolve the

problemIf it only happened once,

it’s not a pattern

WHY SHOULD I CARE ABOUT PATTERNS?

The question of the day!

Guitar

Different implementations, but all recognized as “a guitar”

Kitchen

• Preparing/Cooking food• Store cooking tools• Stove• Refrigerator• Sink• Counter space• Dishwasher

Power of a Pattern Language

• A shared vocabulary• Powerful• Say more with less• Stay “in the design” longer• Turbo charge the team• Gets new hires up to speed

From Architecture to Software

• 1987 – Kent Beck and Ward Cunningham presented at OOPSLA

• 1994 – GoF book published

GOF Pattern Template

• Pattern Name• Classification• Intent• Also Known As• Motivation• Applicability• Structure

• Participants• Collaborations• Consequences• Implementation• Sample Code• Known Uses• Related Patterns

GoF Pattern CatalogCreational Patterns• Abstract Factory Creates an instance of several families of

classes• Builder Separates object construction from its

representation• Factory Method Creates an instance of several derived

classes• Prototype A fully initialized instance to be copied or

cloned• Singleton A class of which only a single instance can

exist

Structural Patterns• Adapter Match interfaces of different classes• Bridge Separates an object’s interface from its

implementation• Composite A tree structure of simple and composite

objects• Decorator Add responsibilities to objects dynamically• Facade A single class that represents an entire

subsystem• Flyweight A fine-grained instance used for efficient

sharing• Proxy An object representing another object

Behavioral Patterns• Chain of Resp. A way of passing a request between a

chain of objects• Command Encapsulate a command request as an object• Interpreter A way to include language elements in a

program• Iterator Sequentially access the elements of a

collection• Mediator Defines simplified communication between

classes• Memento Capture and restore an object's internal state• Observer A way of notifying change to a number of

classes• State Alter an object's behavior when its state changes• Strategy Encapsulates an algorithm inside a class• Template Method Defer the exact steps of an

algorithm to a subclass• Visitor Defines a new operation to a class without

change

GoF Classification

We need some code that…

Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

Observer Pattern

• Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

• Also Known As: Publish-Subscribe

Patterns are not created…

They arediscovered!

LET’S DISCOVER A PATTERN!Object oriented principles sneak in

Duck Simulator

Adding “fly()”

But RubberDuck now flies…

Override fly?

One possible solution

But what happens when we have this?

Interfaces?

Encapsulate what varies

Important OOP Principle!

Behaviors separated

The New Duck

Important OOP Principle!

Program to an interface, not an implementation

Delegate the behavior

Implementation specifies behavior

The Strategy Pattern

Patterns are not created…

They arediscovered!

OO Principles

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

interact.• Open for extension but closed for modification.• Depend on abstractions.• Only talk to your friends.• Don't call us, we'll call you.• A class should have only one reason to change.

Beyond

• Architectural• Application• Domain-Specific• Business Process• Organizational• User Interface Design

Anti-Patterns

• Why the bad solution is unattractive• Why in the long term it’s bad• Suggests other patterns for a good solution

Tells you how to go from a problem to a BAD solution.

Catalog…

• Big Ball of Mud• Gold Plating• Interface Bloat• God Object• Coding by Exception• Copy and Paste• Golden Hammer• Cargo Cult

• Analysis Paralysis• Design by Committee• Vendor Lock-in• Groupthink• Mushroom

Management

Share the Vocabulary

1) In design meetings2) With other developers3) In architecture documentation4) In code comments and naming conventions5) To groups of interested developers

Learning more…I really like this one… some people find it annoying. Puts Design Patterns in the context of OOP.

Great reference. Definitive resource. Put me to sleep the first couple times I tried to read it though.

My Contact Info

• @mdclement• mike@softwareontheside.com• http://blog.softwareontheside.com• Utah Software Craftsmanship Group– https://groups.google.com/forum/#!

forum/ut-software-craftsmanship– @utahsc