Power of Patterns OR More Than Programming with Objects

Power of PatternsORMore Than Programming with Objects
Intro to Design Patterns
Mike Clement
@mdclement
mike@softwareontheside.com
http://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 problem
If 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 Catalog
Creational 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 are
discovered!

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
Program to an interface, not an implementation
Important OOP Principle!

Delegate the behavior

Implementation specifies behavior

The Strategy Pattern

Patterns are not created…
They are
discovered!

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
Tells you how to go from a problem to a BAD solution.
Why the bad solution is unattractive
Why in the long term it’s bad
Suggests other patterns for a good 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
In design meetings
With other developers
In architecture documentation
In code comments and naming conventions
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

Power of Patterns OR More Than Programming with Objects

by Mike Clement on Sep 13, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 308

Statistics

Power of Patterns OR More Than Programming with Objects — Presentation Transcript

http://blog.softwareontheside.com	306
http://feeds.feedburner.com	2