Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Power of Patterns OR More Than Programming with Objects

2,007 views

Published on

An Introduction to Design Patterns. 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!) We'll talk about why you should know common design patterns, why they are powerful and how to make sure you're leveraging object oriented programming principles, not just "programming with objects".

  • Be the first to comment

Power of Patterns OR More Than Programming with Objects

  1. 1. Power of PatternsORMore Than Programming with Objects<br />Intro to Design Patterns<br />Mike Clement<br />@mdclement<br />mike@softwareontheside.com<br />http://blog.softwareontheside.com<br />Utah Code Camp Fall 2011<br />
  2. 2. Design Patterns Defined<br />Alexander’s Architecture Design Patterns<br />Published in 1977<br />
  3. 3. “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.”<br />-Christopher Alexander<br />
  4. 4. A Pattern is a solution to a problem in a context<br />Context – recurring situation<br />Problem – goal and constraints<br />Solution – general design to resolve the problem<br />If it only happened once, it’s not a pattern<br />
  5. 5. Why should I care About Patterns?<br />The question of the day!<br />
  6. 6. Guitar<br />Different implementations, but all recognized as “a guitar”<br />
  7. 7. Kitchen<br />Preparing/Cooking food<br />Store cooking tools<br />Stove<br />Refrigerator<br />Sink<br />Counter space<br />Dishwasher<br />
  8. 8. Power of a Pattern Language<br />A shared vocabulary<br />Powerful<br />Say more with less<br />Stay “in the design” longer<br />Turbo charge the team<br />Gets new hires up to speed<br />
  9. 9. From Architecture to Software<br />1987 – Kent Beck and Ward Cunningham presented at OOPSLA<br />1994 – GoF book published<br />
  10. 10. GOF Pattern Template<br />Pattern Name<br />Classification<br />Intent<br />Also Known As<br />Motivation<br />Applicability<br />Structure<br />Participants<br />Collaborations<br />Consequences<br />Implementation<br />Sample Code<br />Known Uses<br />Related Patterns<br />
  11. 11. GoF Pattern Catalog<br />Creational Patterns<br />Abstract Factory Creates an instance of several families of classes<br />Builder Separates object construction from its representation<br />Factory Method Creates an instance of several derived classes<br />Prototype A fully initialized instance to be copied or cloned<br />Singleton A class of which only a single instance can exist<br />Structural Patterns<br />Adapter Match interfaces of different classes<br />Bridge Separates an object’s interface from its implementation<br />Composite A tree structure of simple and composite objects<br />Decorator Add responsibilities to objects dynamically<br />Facade A single class that represents an entire subsystem<br />Flyweight A fine-grained instance used for efficient sharing<br />Proxy An object representing another object<br />Behavioral Patterns<br />Chain of Resp. A way of passing a request between a chain of objects<br />Command Encapsulate a command request as an object<br />Interpreter A way to include language elements in a program<br />Iterator Sequentially access the elements of a collection<br />Mediator Defines simplified communication between classes<br />Memento Capture and restore an object's internal state<br />Observer A way of notifying change to a number of classes<br />State Alter an object's behavior when its state changes<br />Strategy Encapsulates an algorithm inside a class<br />Template Method Defer the exact steps of an algorithm to a subclass<br />Visitor Defines a new operation to a class without change<br />
  12. 12. GoF Classification<br />
  13. 13. We need some code that…<br />Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically<br />
  14. 14. Observer Pattern<br />Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically<br />Also Known As: Publish-Subscribe<br />
  15. 15.
  16. 16.
  17. 17. Patterns are not created…<br />They are<br />discovered!<br />
  18. 18. Let’s discover a pattern!<br />Object oriented principles sneak in<br />
  19. 19. Duck Simulator<br />
  20. 20. Adding “fly()”<br />
  21. 21. But RubberDuck now flies…<br />
  22. 22. Override fly?<br />One possible solution<br />But what happens when we have this?<br />
  23. 23. Interfaces?<br />
  24. 24. Encapsulate what varies<br />Important OOP Principle!<br />
  25. 25. Behaviors separated<br />
  26. 26. The New Duck<br />Program to an interface, not an implementation<br />Important OOP Principle!<br />
  27. 27. Delegate the behavior<br />
  28. 28. Implementation specifies behavior<br />
  29. 29. The Strategy Pattern<br />
  30. 30. Patterns are not created…<br />They are<br />discovered!<br />
  31. 31. OO Principles<br />Encapsulate what varies.<br />Favor composition over inheritance.<br />Program to interfaces, not implementations.<br />Strive for loosely coupled designs between objects that interact.<br />Open for extension but closed for modification.<br />Depend on abstractions.<br />Only talk to your friends.<br />Don't call us, we'll call you.<br />A class should have only one reason to change.<br />
  32. 32. Beyond<br />Architectural<br />Application<br />Domain-Specific<br />Business Process<br />Organizational<br />User Interface Design<br />
  33. 33. Anti-Patterns<br />Tells you how to go from a problem to a BAD solution.<br />Why the bad solution is unattractive<br />Why in the long term it’s bad<br />Suggests other patterns for a good solution<br />
  34. 34. Catalog…<br />Big Ball of Mud<br />Gold Plating<br />Interface Bloat<br />God Object<br />Coding by Exception<br />Copy and Paste<br />Golden Hammer<br />Cargo Cult<br />Analysis Paralysis<br />Design by Committee<br />Vendor Lock-in<br />Groupthink<br />Mushroom Management<br />
  35. 35.
  36. 36.
  37. 37. Share the Vocabulary<br />In design meetings<br />With other developers<br />In architecture documentation<br />In code comments and naming conventions<br />To groups of interested developers<br />
  38. 38. Learning more…<br />I really like this one… some people find it annoying. Puts Design Patterns in the context of OOP.<br />Great reference. Definitive resource. Put me to sleep the first couple times I tried to read it though.<br />
  39. 39. My Contact Info<br />@mdclement<br />mike@softwareontheside.com<br />http://blog.softwareontheside.com<br />Utah Software Craftsmanship Group<br />https://groups.google.com/forum/#!forum/ut-software-craftsmanship<br />@utahsc<br />

×