Design Pattern Zoology
Download as PPT, PDF2 likes1,166 views
This document provides an overview of design patterns, including: 1) Design patterns are general solutions to common programming problems and help simplify code structure by promoting loose coupling and high cohesion. 2) Common design patterns include Strategy, Decorator, Observer, and Chain of Responsibility. Strategy defines behaviors through a common interface. Decorator adds behaviors dynamically. Observer uses publish-subscribe to broadcast events. Chain of Responsibility passes requests between handlers in a chain. 3) Design patterns derive from each other - for example, Decorator and Observer are forms of Chain of Responsibility that always run all handlers. Patterns help decrease coupling and increase cohesion in code.
Design Pattern Zoology
- 1. Design Pattern Zoology Taxonomy and Field Guide of Common Design Patterns Josh Adell <josh.adell@gmail.com> 20120719
- 2. @josh_adell • Software developer: PHP, Javascript, SQL • http://www.dunnwell.com • http://joshadell.com • http://mojolive.com/profile/joshadell • http://github.com/jadell/neo4jphp • http://frostymug.herokuapp.com
- 4. Coming Soon... • What are design patterns? • Why design patterns? • Common design patterns with examples
- 5. Stages of OOP Larva
- 6. Stages of OOP Pupa
- 7. Stages of OOP Adult
- 8. Design Patterns Are • General solutions to common problems • Architectural templates • Named approaches to code structure
- 9. Design Patterns Are Not • Off-the-shelf solutions • One-size-fits-all panacea
- 10. Anti-patterns • Poorly or inappropriately used patterns • Increase code complexity and/or fragility
- 11. Why use design patterns? • Proven solutions • Simplify code structure • Promote loose coupling, high cohesion • Enhance testing/testability Design Patterns are where the power of OOP comes from
- 12. SOLID Principles • Single Responsibility • Open/Closed • Liskov Substitution • Interface Segregation • Dependency Inversion
- 13. Common Themes • Code to an Interface, not an Implementation • One class == one responsibility • Favor Compostion over Inheritance • Replace branching with polymorphism • Low coupling, high cohesion
- 14. Types of Patterns • Architectural • Code o Client-Server o Adapter o Cloud o Chain-of-Command o Command • Application o Decorator o MVC o Delegate o Services o Factory o Message Queue o Flyweight o Observer • UX o Singleton o Call to Action o Strategy o Progressive o Visitor disclosure
- 16. Strategy • Define a family of behaviors • Each behavior is accessed via a common interface • Client code doesn't care which behavior it uses • Behaviors can be shared across class hierarchies
- 17. Delegate • Delegator passes a request to a helper (the delegate) • Delegate handles request, passes result back • Delegator passes result back to caller
- 18. Decorator • Add behaviors to a base object dynamically • Base decorator passes through unmodified • Decorators that modify requests or responses • Decorators wrap a base object or decorator
- 19. Chain-of-Responsibility • Dispatcher calls a handler, that calls a handler... • Each handler responsible for passing to next • Stop when event is handled
- 20. Observer • Publish-subscribe • Broadcast an event, all observers catch and handle • Broadcaster doesn't care about observers
- 21. Patterns derive from each other • Delegate is based on Strategy • CoR is a string of Delegates that call each other • Decorator & Observer are CoR that always run to the end
- 22. Wrap Up • More patterns out there: Command, Facade, Pool, Mediator, Visitor, Adapter • Use this vocabulary during technical discussions • Refactor spaghetti and long-winded code • Decrease coupling, increase cohesion!
- 23. Good References • http://www.oodesign.com • Gang of Four - Gamma, Helm, Johnson, Vlissides • Head-First Design Patterns
- 24. Questions?
Editor's Notes
- #6: * Use classes to hold data structures together * Logic is procedural * Ask for data, but operates on data outside of where the data resides * Rules are hard-coded * Stage 0: Egg, all code is procedural, global state, arrays/scalars for data
- #7: * Use classes to hold data structures together, and provide behaviors for maintaining the data * Ensure data integrity * Most logic is still procedural, hard-coded
- #8: * Use classes to hold data structures together, and provide behaviors for maintaining the data * Objects also represent behavior, not just data * Logic comes from the interaction of objects via contracts/interfaces * Behavior emerges from interactions, not predetermined rules
- #9: * Gang of Four * Best practices
- #10: * No one-size-fits-all * Require forethought to determine which pattern is appropriate * No excuse for poorly designed code
- #11: * pre-mature optimization * misunderstood refactoring * Any pattern taken to an extreme can become an anti-pattern
- #12: * Provide a common vocabulary for discussing architecture * Simplicity through code re-use * Coupling: unnecessary linking of one component to another. Hard to change one without changing the other. * Solve by coding to an interface! * Cohesion: component parts fit together in logical, narrowly-defined ways. * One class or method = one responsibility
- #13: * An object has only one responsibility * Objects are open for extension but closed for modification * Any entity can be replaced by a sub-type of that entity (or one that meets the same contract) * Many specific interfaces are better than one general interface * Depend on contracts/interfaces, not concrete instantiations
- #14: * themes that underly all the design patterns * at least the ones we're going to talk about * De-coupling * Tight cohesion * small classes and methods are easier to work with than large ones * easier to debug * easier to test! * Dependency Injection * Objects create objects or do business logic, not both
- #15: * architectural: how systems fit together, interact * application: how code systems are divided, layered * Code: how code logic is divided, behaves and interacts * Common to all: how bits of a system talk to each other, pass information (code, servers, users) * You've probably used these patterns without knowing it, or knowing their names
- #16: * Next slides: * Introduce a pattern * Concept * When to use * Show an example
- #17: * Very common pattern, can be seen as the basis for many other patterns * If you learn only one, learn this one! * Each behavior is its own class * Behavior can be selected and changed at runtime * Behavior not tied to client * Composition over inheritance! * Unit testing tip: pass in a mock strategy to test that client calls it correctly Use when: * behavior needed across multiple classes/heirarchies * behavior needs to change dynamically
- #18: * Strategy's brother * Code sample-1 * Code sample-2 Use when: * Single object has a wide interface
- #19: * Classis example is ordering pizza, coffee, car options * Notice that no decorator knows if it's talking to a decorator or the base object. * Can unit test decorator by passing in a mock base, know it will work on any decorator or base in the family * Code sample-3 Use when: * Behaviors are conditional * Behaviors are chained * Order (probably) doesn't matter
- #20: * Also see this called &quot;Chain of Command&quot; * I used to call it this, but saw people get it confused with the actual &quot;Command&quot; pattern * Dispatcher only knows the first handler * Dispatcher doesn't care who handled the event, only that it was or was not handled * Handlers handle their own errors internally, should not affect dispatcher or any other handler * Code sample-4 * Code sample-5 Use when: * More than one way to handle an event * How it's handled doesn't matter; just that it is handled or not
- #21: * Broadcast is an event and any associated parameters * Subscribers can request only to hear about specific events * Subscribers must cleanup after themselves, handle their own failure * Decouples generation of event from its handling * Doctrine * Javascript in general * Code sample-6 Use when: * Event triggers many independent behaviors * Event generator doesn't care about results * State changes need to be known by many objects
- #22: * Said before, if you only learn one, learn Strategy. * All other can be derived from it