Lecture 19: Introduction to Design Patterns
Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov. 6, 2008
¾ 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 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) Buschmann, Meunier, Rohnert, Sommerlad, Stal ¾ Many more Conferences, symposia, other books
3 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 Types of Patterns
¾ Behavioral Observer Mediator ¾ Structural Adapter Façade Proxy ¾ Creational Abstract Factory
5 Patterns by Example: Multiple Displays Enabled by Observer
Relative Percentages A B C D A X 15 35 35 15 D Y 10 40 30 20 B C Z 10 40 30 20 A B C D
A=10% B=40% C=30% Application data Change notification D=20%
Requests, modifications 6 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 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 The Observer Pattern
Subject Observer
attach (Observer) update() detach (Observer) For all x in observers{ notify () x.update(); }
Concrete Observer
Concrete Subject observerState subjectState
setState() observerState= getState() subject Æ getState(); 9 The Observer Pattern
¾ Sequence diagram
10 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 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 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 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 MVC Solution:
Static Structure Observer
update() Model For all x in observers{ x.update(); } attach (Observer) detach (Observer) notify () View Controller getData performService myModel myModel represents myController myController manipulates initialize(Model) initialize(Model, View) makeController handleEvent(Event) activate() update() display() update()
calls-service-on 15 MVC Solution: Behavior
16 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 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 Observer and MVC
¾ Observer is a design pattern ¾ MVC often uses Observer to decouple Model and View
19 Observer’s Relationship to MVC
¾ One way to think about MVC at mid-level design (without the observer pattern):
:Model :View The model keeps track of all views. (make some change to state) The model is updated then tells each view that the updateBarGraph(b) model was updated…
updatePieChart(p)
20 Observer’s Relationship to MVC
¾ MVC design decoupled with the Observer pattern:
The View previously :Model :View registered interest in changes to model… notify() …now, the model doesn’t need to know anything update() about the views…
getData() …it just notifies registered parties of interest when state changes.
21