1 / 27

Design Patterns

Design Patterns. John Reekie j ohn.reekie@uts.edu.au. Software Architecture 48433 21 st August 2003. Background. Gamma, Helm, Johnson, and Vlissides (the “Gang of Four”) – Design Patterns, Elements of Reusable Object-Oriented Software

tamarr
Télécharger la présentation

Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Patterns John Reekie john.reekie@uts.edu.au Software Architecture 48433 21st August 2003

  2. Background • Gamma, Helm, Johnson, and Vlissides (the “Gang of Four”) – Design Patterns, Elements of Reusable Object-Oriented Software • This book solidified thinking about patterns and became the seminal Design Patterns text • Software design patterns are based (somewhat) on work by the architect Christopher Alexander

  3. Purpose • A design pattern captures design expertise –patterns are not created from thin air, but abstracted from existing design examples • Using design patterns is reuse of design expertise • Studying design patterns is a way of studying how the “experts” do design • Design patterns provide a vocabulary for talking about design

  4. On vocabulary “Longitudinally-mounted 90-degree V-twin” “Torque” “Growl” “Perfect primary balance” Images from http://www.ducati.com

  5. On vocabulary (2) “Transverse inline four” “Power peak” “Screamer” Images from http://www.tntperformancedyno.com, http://dsr.racer.net and http://www.motorcycle.com

  6. Why design patterns in SA? • If you’re a software engineer, you should know about them anyway • There are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: • Mowbray and Malveau – CORBA Design Patterns • Schmidt et al – Pattern-Oriented Software Architecture • Design Patterns help you break out of first-generation OO thought patterns

  7. ORB The seven layers of architecture* OO architecture Global architecture Enterprise architecture Subsystem System architecture Application architecture Frameworks Macro-architecture Design patterns Micro-architecture Objects OO programming * Mowbray and Malveau

  8. How patterns arise Problem Context Forces Solution Benefits Consequences Related Patterns

  9. Structure of a pattern • Name • Intent • Motivation • Applicability • Structure • Consequences • Implementation • Known Uses • Related Patterns

  10. Key patterns • The following patterns are what I consider to be a good “basic” set of design patterns • Competence in recognizing and applying these patterns will improve your low-level design skills • (The slides are necessarily brief and do not follow the structure just given above!)

  11. Composite • Construct part-whole hierarchy • Simplify client interface to leaves/composites • Easier to add new kinds of components 0..* Client Component Operation() Add(Component) Remove(Component) children Leaf Composite Operation() Operation() Add(Component) Remove(Component) For all c in children c.Operation();

  12. Composite (2) • Example: figures in a structured graphics toolkit Controller 0..* 0..* View Figure children paint() translate() getBounds() BasicFigure LabelFigure CompositeFigure parent paint() paint() addFigure(Figure)) removeFigure(Figure)) paint() For all c in children c.paint();

  13. Facade • Provide unified interface to interfaces within a subsystem • Shield clients from subsystem components • Promote weak coupling between client and subsystem components Client Facade

  14. Façade (2) • Example: graph interface to a simulation engine SchematicEditor Graph Director 2 0..* Relation Port Entity BufferedRelation AtomicEntity CompositeEntity Token Actor

  15. Strategy • Make algorithms interchangeable---”changing the guts” • Alternative to subclassing • Choice of implementation at run-time • Increases run-time complexity Context Strategy ContextInterface() Operation() ConcreteStrategy2 ConcreteStrategy1 Operation() Operation()

  16. Strategy (2) • Example: drawing different connector styles shape=router.recalculate(start,end); redraw(shape); Connector ConnectorRouter route() Shape recalculate(Pt, Pt) ArcRouter StraightRouter ManhattanRouter Shape recalculate(Pt, Pt) Shape recalculate(Pt, Pt) Shape recalculate(Pt, Pt)

  17. Observer • Many-to-one dependency between objects • Use when there are two or more views on the same “data” • aka “Publish and subscribe” mechanism • Choice of “push” or “pull” notification styles Subject Observer attach(Observer) detach(Observer) notify() update() forall o in observers o.update() ConcreteSubject ConcreteObserver getState() update() state=subject.getState();

  18. Observer(2) Observer • Example: subscribing to events (Diagram not done, sorry!)

  19. Factory Method • Defer object instantiation to subclasses • Eliminates binding of application-specific subclasses • Connects parallel class hierarchies • A related pattern is AbstractFactory Product Creator operation() Product createProduct() ConcreteProduct ConcreteCreator operation() Product createProduct() return new ConcreteProduct();

  20. Factory Method (2) • Example: creating manipulators on connectors Interactor 0..1 Figure Manipulator createManipulator() attach(Figure) ArcManipulator RectFigure Connector BoundsManipulator attach(Figure) attach(Figure) createManipulator() createManipulator() manip = new ArcManipulator(); manip = new BoundsManipulator();

  21. Chain of Responsibility • Decouple sender of a request from receiver • Give more than one object a chance to handle • Flexibility in assigning responsibility • Often applied with Composite successor Client Handler ContextInterface() handleRequest() ConcreteHandler2 ConcreteHandler1 handleRequest() handleRequest()

  22. Chain of Responsibility (2) • Example: handling events in a graphical hierarchy If interactor != null interactor.handle(event,this) else parent.handleEvent(event) 0..* 0..1 0..* Interactor Figure children handle(Event,Figure) handleEvent(Event) CompositeFigure parent

  23. Patterns vs “Design” • Patterns are design • But: patterns transcend the “identify classes and associations” approach to design • Instead: learn to recognize patterns in the problem space and translate to the solution • Patterns can capture OO design principles within a specific domain • Patterns provide structure to “design”

  24. Patterns vs Frameworks • Patterns are lower-level than frameworks • Frameworks typically employ many patterns: • Factory • Strategy • Composite • Observer • Done well, patterns are the “plumbing” of a framework

  25. Patterns vs Architecture • Design Patterns (GoF) represent a lower level of system structure than “architecture” (cf: seven levels of A) • Patterns can be applied to architecture: • Mowbray and Malveau • Buschmann et al • Schmidt et al • Architectural patterns tend to be focussed on middleware. They are good at capturing: • Concurrency • Distribution • Synchronization

  26. Online resources • Pattern FAQ • http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html • Basic patterns • http://exciton.cs.oberlin.edu/javaresources/DesignPatterns/default.htm • Patterns home page • http://hillside.net/patterns/

  27. Concluding remarks • Design Patterns (GoF) provide a foundation for further understanding of: • Object-Oriented design • Software Architecture • Understanding patterns can take some time • Re-reading them over time helps • As does applying them in your own designs!

More Related