Lecture 19: Introduction to Design Patterns

Transcription

1 Lecture 19: Introduction to Design Patterns Software System Design and Implementation ITCS/ITIS 6112/ Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov. 6,

2 Design Patterns A design pattern is a way of reusing abstract knowledge about a problem and its solution Patterns allow programmers to share knowledge about design A pattern is a description of the problem and the essence of its solution A pattern should be sufficiently abstract to be reused in different settings 2

3 History of Design Patterns Architect Christopher Alexander A Pattern Language (1977) A Timeless Way of Building (1979) Gang of four (GoF) Gamma, Helm, Johnson, Vlissides Design Patterns: Elements of Reusable Object-Oriented Software (1995) Pattern-oriented Software Architecture (POSA) Many more Buschmann, Meunier, Rohnert, Sommerlad, Stal Conferences, symposia, other books 3

4 Pattern Elements Name A meaningful pattern identifier Problem description (Applicability) Solution description Not a concrete design but a template for a design solution that can be instantiated in different ways Text Models Static structure (class diagrams) Behavior (sequence diagrams) Consequences The results and trade-offs of applying the pattern 4

5 Types of Patterns Behavioral Observer Mediator Structural Adapter Façade Proxy Creational Abstract Factory 5

6 Patterns by Example: Multiple Displays Enabled by Observer A B C D X Y Z Relative Percentages A B C D D C A B Change notification A=10% B=40% C=30% D=20% Application data Requests, modifications 6

7 The Observer Pattern Name Observer a.k.a. publish-subscribe Description/Applicability General: When change in object state requires consistent reflection of change in other objects Want dependent objects to be decoupled from one another Specific: Separates the display of object state from the object itself Problem description Used when multiple displays of state are needed need changes to state to be reflected consistently across all displays 7

8 The Observer Pattern Solution description Use a change-propagation mechanism between info provider (subject) and the components that use it to display (observers) Subject Stores state of interest Provides ability for Observers to attach/detach Calls Observer s update interface Observer Provides an update interface Attaches and detaches itself from Subject 8

9 The Observer Pattern Subject attach (Observer) detach (Observer) notify () Concrete Subject subjectstate setstate() getstate() For all x in observers{ x.update(); } Observer update() Concrete Observer observerstate observerstate= subject getstate(); 9

10 The Observer Pattern Sequence diagram 10

11 Observer Pattern Consequences Can add/remove observers at any time without modifying subject Can reuse subjects without reusing observers (and vice-versa) Unexpected updates to subject can cause a cascade of unnecessary update operations on observer 11

12 An Aside: Observer and MVC People often confuse the Observer design pattern with the MVC architectural style MVC describes an architecture: Model Manages data Executes business processing operations View Displays information and supports user interaction That is, the user interface Controller Processes and responds to events Notifies model of events Typically responds to user input and invokes operation/change on model 12

13 Architectural Style Example: Model-View-Controller (MVC) Applicability Interactive applications with a flexible human-computer interface Problem context The display presented to the user frequently changes over time in response to input or computation Different users have different needs for how they want to view the program s information Want to reflect data changes to all users in the way that they want to view them Want to make it easy to make changes to the user interface 13

14 Model-View-Controller (MVC) Solution: separate the data being manipulated from the manipulation logic and the details of display Three components: Model A problem-domain component with data and operations for achieving program goals independent of the user interface View A data display component Controller A component that receives and acts on user input 14

15 MVC Solution: Static Structure Observer Model attach (Observer) For all x in observers{ x.update(); } update() detach (Observer) notify () getdata performservice represents View mymodel mycontroller initialize(model) makecontroller activate() display() update() manipulates Controller mymodel mycontroller initialize(model, View) handleevent(event) update() calls-service-on 15

16 MVC Solution: Behavior 16

17 Consequences: MVC Advantages Views and controllers can be easily be added, removed, or changed No need to change the domain-specific data model Views can be added or changed during execution User interface components can be changed, even at runtime 17

18 Consequences: MVC Disadvantages Views and controller are often hard to separate Frequent updates may slow data display and degrade user interface performance The MVC style makes user interface components highly dependent on model components 18

19 Observer and MVC Observer is a design pattern MVC often uses Observer to decouple Model and View 19

20 Observer s Relationship to MVC One way to think about MVC at mid-level design (without the observer pattern): :Model :View (make some change to state) updatebargraph(b) The model keeps track of all views. The model is updated then tells each view that the model was updated updatepiechart(p) 20

21 Observer s Relationship to MVC MVC design decoupled with the Observer pattern: :Model notify() update() :View The View previously registered interest in changes to model now, the model doesn t need to know anything about the views getdata() it just notifies registered parties of interest when state changes. 21