Power of Patterns: Refactoring to (or away from) Patterns

68
Power of Patterns: Refactoring to (or away from) Patterns Mike Clement @mdclement [email protected] http://blog.softwareontheside.com http://agilecodegames.com

description

What is a design pattern? Why should you care? What it the power of design patterns? How do design patterns tie into object oriented programming? If I'm using objects in my code, isn't that object oriented programming? (The answer is not necessarily!) When should I use them? Design Patterns are great but the temptation is to use Design Patterns as a golden hammer. This can lead to unnecessarily complicated, over-engineered code in an effort to be flexible and ready for the future. That sounds reasonable - if you happen to be a psychic. More commonly, you will refactor to a pattern when the code (that you’ve written simply and minimally) demands it. We'll talk about why you should know common design patterns, why they are powerful, how they relate to object oriented principles, different composite refactorings that will move you to (and sometimes away) from patterns and the smells that help you know when to apply them.

Transcript of Power of Patterns: Refactoring to (or away from) Patterns

Page 1: Power of Patterns: Refactoring to (or away from) Patterns

Power of Patterns:Refactoring to (or away from)

Patterns

Mike Clement@mdclement

[email protected]://blog.softwareontheside.com

http://agilecodegames.com

Page 2: Power of Patterns: Refactoring to (or away from) Patterns

Design Patterns Defined

• Alexander’s Architecture Design Patterns

• Published in 1977

Page 3: Power of Patterns: Refactoring to (or away from) Patterns

“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

Page 4: Power of Patterns: Refactoring to (or away from) Patterns

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

Page 5: Power of Patterns: Refactoring to (or away from) Patterns

WHY SHOULD I CARE ABOUT PATTERNS?

Page 6: Power of Patterns: Refactoring to (or away from) Patterns

Different implementations, but all recognized as “a guitar”

Page 7: Power of Patterns: Refactoring to (or away from) Patterns

Kitchen

• Preparing/Cooking food• Stove• Refrigerator• Sink• Counter space• Storage/Cabinets/Drawers• Dishwasher

Page 8: Power of Patterns: Refactoring to (or away from) Patterns

Power of a Pattern Language

• Say more with less• Better communication• Stay “in the design” longer• A shared vocabulary

Page 9: Power of Patterns: Refactoring to (or away from) Patterns

From Architecture to Software

• 1987 – Kent Beck and Ward Cunningham presented at OOPSLA

• 1994 – GoF book published

Page 10: Power of Patterns: Refactoring to (or away from) Patterns

GOF Pattern Template

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

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

Page 11: Power of Patterns: Refactoring to (or away from) Patterns

We need some code that…

When weather/stock/employee data is updated, all the clients are notified of the change.

Page 12: Power of Patterns: Refactoring to (or away from) Patterns

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

Page 13: Power of Patterns: Refactoring to (or away from) Patterns
Page 14: Power of Patterns: Refactoring to (or away from) Patterns

Patterns are not created…

They arediscovered!

Page 15: Power of Patterns: Refactoring to (or away from) Patterns

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

Page 16: Power of Patterns: Refactoring to (or away from) Patterns

Duck Simulator

Page 17: Power of Patterns: Refactoring to (or away from) Patterns

Adding “fly()”

Page 18: Power of Patterns: Refactoring to (or away from) Patterns

But RubberDuck now flies…

Page 19: Power of Patterns: Refactoring to (or away from) Patterns

Override fly?

One possible solution

But what happens when we have this?

Page 20: Power of Patterns: Refactoring to (or away from) Patterns

Interfaces?

Page 21: Power of Patterns: Refactoring to (or away from) Patterns

Encapsulate what varies

Important OOP Principle!

Page 22: Power of Patterns: Refactoring to (or away from) Patterns

Behaviors separated

Page 23: Power of Patterns: Refactoring to (or away from) Patterns

The New Duck

Important OOP Principle!

Program to an interface, not an implementation

Page 24: Power of Patterns: Refactoring to (or away from) Patterns

Delegate the behavior

Page 25: Power of Patterns: Refactoring to (or away from) Patterns

The Strategy Pattern

Page 26: Power of Patterns: Refactoring to (or away from) Patterns

Patterns are not created…

They arediscovered!

Page 27: Power of Patterns: Refactoring to (or away from) Patterns

WHEN?

Page 28: Power of Patterns: Refactoring to (or away from) Patterns

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.

Page 29: Power of Patterns: Refactoring to (or away from) Patterns

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

Page 30: Power of Patterns: Refactoring to (or away from) Patterns
Page 31: Power of Patterns: Refactoring to (or away from) Patterns
Page 32: Power of Patterns: Refactoring to (or away from) Patterns

WHEN?

Page 33: Power of Patterns: Refactoring to (or away from) Patterns
Page 34: Power of Patterns: Refactoring to (or away from) Patterns
Page 35: Power of Patterns: Refactoring to (or away from) Patterns
Page 36: Power of Patterns: Refactoring to (or away from) Patterns

XP Simple Design

• Passes all tests• Clear, expressive, consistent• No duplication•Minimal

Page 37: Power of Patterns: Refactoring to (or away from) Patterns

WHEN?

Page 38: Power of Patterns: Refactoring to (or away from) Patterns

SO WHAT ABOUT REFACTORING?

Page 39: Power of Patterns: Refactoring to (or away from) Patterns

Code Smells• Duplicated Code• Long Method• Large Class• Long Parameter List• Divergent Change• Shotgun Surgery• Feature Envy• Data Clumps• Primitive Obsession• Switch Statements• Parallel Inheritance Hierarchies• Lazy Class• Speculative Generality• Temporary Field

• Message Chains• Middle Man• Inappropriate Intimacy• Alternative Classes with Different

Interfaces• Incomplete Library Class• Data Class• Refused Bequest• Comments• Conditional Complexity• Indecent Exposure• Solution Sprawl• Combinatorial Explosion• Oddball Solution

From Refactoring and Refactoring to Patterns

Page 40: Power of Patterns: Refactoring to (or away from) Patterns

• Extract Method• Inline Method• Move Method• Extract Class• Encapsulate Field• Rename Method• Add Parameter• Remove Parameter• Encapsulate Downcast• Pull Up Method• Push Down Method• Extract Superclass• Extract Subclass• Extract Interface

Page 41: Power of Patterns: Refactoring to (or away from) Patterns
Page 42: Power of Patterns: Refactoring to (or away from) Patterns

“There is a natural relation between patterns and refactoring. Patterns are where you want to be; refactorings are ways to get there from somewhere else.”

Refactoring p. 107

Page 43: Power of Patterns: Refactoring to (or away from) Patterns
Page 44: Power of Patterns: Refactoring to (or away from) Patterns

Pattern To Towards AwayAdapter Extract Adapter (258),Unify Interfaces with Adapter(247) Unify Interfaces with

Adapter(247)

Builder Encapsulate Composite with Builder(96)

Collecting Parameter Move Accumulation to Collecting Parameter(313)

Command Replace Conditional Dispatcher with Command(191) Replace Conditional Dispatcher with Command(191)

Composed Method Compose Method (123) Composite Replace One/Many Distinctions with Composite(224), Extract

Composite(214), Replace Implicit Tree with Composite(178) Encapsulate Composite with

Builder(96)

Creation Method Replace Constructors with Creation Methods (57)

Decorator Move Embellishment to Decorator(144) Move Embellishment to Decorator(144)

Factory Move Creation Knowledge to Factory (68),Encapsulate Classes with Factory (80)

Factory Method Introduce Polymorphic Creation with Factory Method (88)

Interpreter Replace Implicit Language with Interpreter(269)

Iterator Move Accumulation to Visitor(320)

Null Object Introduce Null Object (301) Observer Replace Hard-Coded Notifications with Observer(236) Replace Hard-Coded

Notifications with Observer(236)

Singleton Limit Instantiation with Singleton(296) Inline Singleton(114)

State Replace State-Altering Conditionals with State(166) Replace State-Altering Conditionals with State(166)

Strategy Replace Conditional Logic with Strategy (129) Replace Conditional Logic with Strategy (129)

Template Method Form Template Method (205) Visitor Move Accumulation to Visitor (320) Move Accumulation to

Visitor (320)

Page 45: Power of Patterns: Refactoring to (or away from) Patterns

Smell RefactoringDuplicated Code (39) Form Template Method(205)Introduce Polymorphic Creation with Factory Method(88)

Chain Constructors(340)Replace One/Many Distinctions with Composite (224)Extract Composite(214)Unify Interfaces with Adapter (247)Introduce Null Object(301)

Long Method(40) Compose Method (123)Move Accumulation to Collecting Parameter (313)Replace Conditional Dispatcher with Command (191)Move Accumulation to Visitor (320)Replace Conditional Logic with Strategy(129)

Conditional Complexity(41) Replace Conditional Logic with Strategy(129)Move Embellishment to Decorator (144)Replace State-Altering Conditionals with State (166)Introduce Null Object(301)

Primitive Obsession (41) Replace Type Code with Class (286)Replace State-Altering Conditionals with State ( 166)Replace Conditional Logic with Strategy(129)Replace Implicit Tree with Composite (178)Replace Implicit Language with Interpreter (269)Move Embellishment to Decorator (144)Encapsulate Composite with Builder (96)

Indecent Exposure (42) Encapsulate Classes with Factory (80)Solution Sprawl (43) Move Creation Knowledge to Factory(68)Alternative Classes with Different Interfaces (43)

Unify Interfaces with Adapter (247)

Lazy Class (43) Inline Singleton (114)Large Class(44) Replace Conditional Dispatcher with Command (191)Replace State-Altering Conditionals with State (166)

Replace Implicit Language with Interpreter (269)

Switch Statements(44) Replace Conditional Dispatcher with Command (191) Move Accumulation to Visitor (320)

Combinatorial Explosion (45) Replace Implicit Language with Interpreter (269)

Oddball Solution (45) Unify Interfaces with Adapter (247)

Page 46: Power of Patterns: Refactoring to (or away from) Patterns
Page 47: Power of Patterns: Refactoring to (or away from) Patterns

ENCAPSULATE CREATION WITH FACTORY

Code!

Page 48: Power of Patterns: Refactoring to (or away from) Patterns
Page 49: Power of Patterns: Refactoring to (or away from) Patterns
Page 50: Power of Patterns: Refactoring to (or away from) Patterns

CONDITIONAL TO STRATEGYCode!

Page 51: Power of Patterns: Refactoring to (or away from) Patterns
Page 52: Power of Patterns: Refactoring to (or away from) Patterns
Page 53: Power of Patterns: Refactoring to (or away from) Patterns
Page 54: Power of Patterns: Refactoring to (or away from) Patterns
Page 55: Power of Patterns: Refactoring to (or away from) Patterns

WHEN?

Page 56: Power of Patterns: Refactoring to (or away from) Patterns
Page 57: Power of Patterns: Refactoring to (or away from) Patterns

XP Simple Design

• Passes all tests• Clear, expressive, consistent• No duplication•Minimal?

Page 58: Power of Patterns: Refactoring to (or away from) Patterns
Page 59: Power of Patterns: Refactoring to (or away from) Patterns
Page 60: Power of Patterns: Refactoring to (or away from) Patterns
Page 61: Power of Patterns: Refactoring to (or away from) Patterns

Beyond

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

Page 62: Power of Patterns: Refactoring to (or away from) Patterns

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.

Page 63: Power of Patterns: Refactoring to (or away from) Patterns

Learning more…The “Original” Refactoring book. All your classic refactorings!

Great content and catalog of composite refactorings to help with patterns.

Page 64: Power of Patterns: Refactoring to (or away from) Patterns

Share the Vocabulary

1) In design meetings2) In documentation3) In naming conventions4) To groups of interested developers

Page 65: Power of Patterns: Refactoring to (or away from) Patterns

Action Items!

• Play with Patterns• Share the Vocabulary– Study HFDP with your team

• Build a common language

• Participate in a local Software Craftsmanship group near you!

Page 66: Power of Patterns: Refactoring to (or away from) Patterns
Page 67: Power of Patterns: Refactoring to (or away from) Patterns
Page 68: Power of Patterns: Refactoring to (or away from) Patterns

My Contact Info

• @mdclement• [email protected]• http://blog.softwareontheside.com• http://agilecodegames.com• https://github.com/mdclement• Utah Software Craftsmanship Group– http://utahsc.org– @utahsc