Successfully reported this slideshow.

Design Patterns


Published on

  • Be the first to comment

Design Patterns

  1. 1. Indy Java User’s Group June 29 2005 6:00p.m @ Knowledge Services, Inc.
  2. 2. Agenda <ul><li>Welcome / Pizza 6:00-6:15 </li></ul><ul><li>Introductions 6:15-6:30 </li></ul><ul><li>Design Patterns 6:30-7:30 </li></ul><ul><li>Future JUG Topics 7:30-8:00 </li></ul><ul><li>Giveaways 8:00-8:15 </li></ul>
  3. 3. Mission Statement Promote the use of the Java language and components across all levels of interest in the greater Indianapolis area, by serving as a resource for knowledge , experience and career opportunities .
  4. 4. Introductions <ul><li>Name </li></ul><ul><li>Work </li></ul><ul><li>How long have you been coming? </li></ul><ul><li>Something Interesting </li></ul>
  5. 5. Tonight’s Objective <ul><ul><li>Design Patterns Overview </li></ul></ul><ul><ul><li>Elements of a Design Patterns </li></ul></ul><ul><ul><li>Chain of Responsibility(CoR) Example </li></ul></ul><ul><ul><li>‘ Your Turn’ </li></ul></ul>
  6. 6. Design Patterns (Overview) <ul><ul><li>Goals of Design Patterns </li></ul></ul><ul><ul><li>Benefits of Design Patterns </li></ul></ul><ul><ul><li>Challenges of Design Patterns </li></ul></ul><ul><ul><li>History (Gang of Four) </li></ul></ul>
  7. 7. Design Patterns (Goal) <ul><li>“ Capture solutions that have developed and evolved over time in a succinct and easily applied form.” </li></ul><ul><li>“ Systematically name, explain and evaluate an important and recurring design in object-oriented systems” </li></ul>
  8. 8. Design Patterns (Quote) “ A design pattern isn’t ‘designed’. It’s discovered. In other words, patterns aren’t an invention as much as they are a refactoring of existing concepts.” - A. Russell Jones
  9. 9. Design Patterns (Benefits) <ul><ul><li>Vocabulary </li></ul></ul><ul><ul><li>Reusability </li></ul></ul><ul><ul><li>OO Ideals </li></ul></ul><ul><ul><li>Standardization </li></ul></ul>
  10. 10. Design Patterns (Challenges) <ul><ul><li>“ Define and describe a repetitive activity at a high enough level to be useful across very different applications, yet specific enough to have a single implementation. ” </li></ul></ul><ul><ul><li>Individual interpretation (Design vs. Impl) </li></ul></ul><ul><ul><li>Terminology overloading. </li></ul></ul><ul><ul><li>Implementation (language limitations, etc) </li></ul></ul><ul><ul><ul><li>Singleton example </li></ul></ul></ul>
  11. 11. Design Patterns (Singleton) <ul><ul><li>public static MyObject getInstance(){ </li></ul></ul><ul><ul><ul><li>if( myObject == null ) { </li></ul></ul></ul><ul><ul><ul><ul><li>myObject = new MyObject(this); </li></ul></ul></ul></ul><ul><ul><ul><li>} </li></ul></ul></ul><ul><ul><ul><li>return( myObject ); </li></ul></ul></ul><ul><ul><li>} </li></ul></ul>
  12. 12. Design Patterns (History) <ul><li>Gang of Four </li></ul><ul><ul><li>Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides </li></ul></ul><ul><li>Book </li></ul><ul><li>Design Patterns: </li></ul><ul><li>Elements of Reusable Object-Oriented Software </li></ul><ul><li>ISBN 0-201-63361-2 </li></ul><ul><li>Copyright 1995 by Addison Wesley, Inc. </li></ul>
  13. 13. Design Patterns (Elements-1) <ul><li>Pattern Name (handle) </li></ul><ul><ul><li>Higher level of abstraction </li></ul></ul><ul><ul><li>Vocabulary </li></ul></ul><ul><li>Problem (context) </li></ul><ul><ul><li>Conditions that must be met before the pattern can be applied </li></ul></ul><ul><ul><li>Describe class or object structures </li></ul></ul>
  14. 14. Design Patterns (Elements-2) <ul><li>Solution (elements) </li></ul><ul><ul><li>Relationships </li></ul></ul><ul><ul><li>Responsibilities </li></ul></ul><ul><ul><li>Collaborations </li></ul></ul><ul><li>Consequences (trade-off) </li></ul><ul><ul><li>Flexibility </li></ul></ul><ul><ul><li>Extensibility </li></ul></ul><ul><ul><li>Portability </li></ul></ul>
  15. 15. Design Patterns (Categories) <ul><li>Creational Patterns </li></ul><ul><ul><li>Factory Method, Singleton, Abstract Factory, Builder, Prototype </li></ul></ul><ul><li>Structural Patterns </li></ul><ul><ul><li>Adapter, Decorator, Bridge, Composite, Façade, Flyweight, Proxy </li></ul></ul>
  16. 16. Design Patterns (Categories) <ul><li>Behavioral Patterns </li></ul><ul><ul><li>Command, Iterator, Interpreter, Mediator, </li></ul></ul><ul><ul><li>Chain of Responsibility (CoR), Memento, Observer, State, Strategy, Template Method, Visitor </li></ul></ul>
  17. 17. Design Patterns (Creational) Creational design patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. (Factory, Singleton)
  18. 18. Design Patterns (Structural) Structural design patterns are concerned with how classes and objects are composed to form larger structures. (i.e. Inheritance). (Adapter, Decorator)
  19. 19. Design Patterns (Behavioral) Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects including the communication between them. (Command, Iterator)
  20. 20. Design Patterns (Review) <ul><li>Decorator </li></ul><ul><li>Allows the ability to change the ‘skin’ </li></ul><ul><li>Strategy </li></ul><ul><li>Allows the ability to change the ‘guts’ </li></ul>
  21. 21. Design Patterns (CoR) “ Avoid coupling the sender of a request to its receiver by giving more then one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. ” -GoF
  22. 22. Design Patterns <ul><li>Example </li></ul>
  23. 23. Design Patterns (References) <ul><li> </li></ul><ul><li> </li></ul>
  24. 24. Design Patterns <ul><li>Your Turn!! </li></ul>
  25. 25. Future Topics <ul><li>Recap from 11/2004: </li></ul><ul><ul><li>Sitemesh </li></ul></ul><ul><ul><li>Subversion </li></ul></ul><ul><ul><li>RUP / XP / Agile </li></ul></ul><ul><ul><li>JNDI/LDAP </li></ul></ul><ul><ul><li>Clustering / Deploying various OSs </li></ul></ul><ul><ul><li>Webstart </li></ul></ul><ul><ul><li>PDF Generation </li></ul></ul><ul><ul><li>SOA/SOAP/Web Services </li></ul></ul>
  26. 26. Info <ul><li>Next Meeting - July 27, 2004 </li></ul><ul><ul><li>The Art of Agility and the AUP </li></ul></ul><ul><ul><li>- Agile unified Process - </li></ul></ul><ul><li>Discussion Forum </li></ul><ul><ul><li> </li></ul></ul><ul><li>Website - </li></ul>
  27. 27. Indy Java User’s Group