Design Patterns – part I
Design Patterns – part I 1/32 History
Design Patterns:
I are derived from design patterns from architecture
I their name was introduced to the software engineering by Kent Beck and Ward Cunningham in 1987
I were made popular by Gang of Four in 1995 through book Design Patterns: Elements of Reusable Object-Oriented Software
Design Patterns – part I 2/32 Solutions of design problems
Design Patterns:
I provide tested solutions of problems
I are not algorithms, because they solve design problems and not computational problems
I are abstract description of connections between classes
Design Patterns – part I 3/32 Describing Design Patterns
Minimal description of Design Patterns:
I pattern name
I intent
I solution
I consequences
Design Patterns – part I 4/32 Classification
Classification of design patterns by their purpose
I creational
I structural
I behavioral
Classification of design patterns by their scope
I class
I object
Design Patterns – part I 5/32 Creational Patterns
I Builder (object)
I Abstract Factory (object)
I Factory Method (class)
I Prototype (object)
I Singleton (object)
Design Patterns – part I 6/32 Structural Patterns
I Adapter (class and object)
I Decorator (object)
I Facada (object)
I Composite (object)
I Bridge (object)
I Proxy (object)
I Flyweight (object)
Design Patterns – part I 7/32 Behavioral Patterns
I Interpreter (class)
I Iterator (object)
I Chain of Responsibility (object)
I Mediator (object)
I Template Method (class)
I Observer (object)
I Visitor (object)
I Memento (object)
I Command (object)
I State (object)
I Strategy (object)
Design Patterns – part I 8/32 Software design with patterns
Steps:
I Specyfying set of design patterns in problem domain. I For obtained set of patterns:
I choose pattern, that prepares context of other patterns, I use this pattern for general design of software, I identify additional patterns, that could appear and add them to analysed problem, I execution of above steps for each design pattern from the set.
I Adding details, defining methods and classes.
Design Patterns – part I 9/32 Strategy
Intent
I Strategy lets the algorithm vary independently from clients that use it.
Motivation
I Many algorithms exist for breaking a stream of text into lines. Hard-wiring all such algorithms into the classes that require them isn’t desirable.
Applicability
I many related classes differ only in their behavior I you need different variants of an algorithm I an algorithm uses data that clients shouldn’t know about I a class defines many behaviors, and these appear as multiple conditional statements in its operations.
Design Patterns – part I 10/32 Strategy
Figure: Structure
Design Patterns – part I 11/32 Strategy
Participants
I Strategy
I ConcreteStrategy
I Context
Collaborations
I Strategy and Context interact to implement the chosen algorithm.
I A context forwards requests from its clients to its strategy.
Design Patterns – part I 12/32 Strategy
Consequences
I Families of related algorithms.
I An alternative to subclassing.
I Strategies eliminate conditional statements.
I A choice of implementations.
I Clients must be aware of different Strategies.
I Communication overhead between Strategy and Context.
I Increased number of objects.
Design Patterns – part I 13/32 Strategy
Implementation
template
c l a s s MyStrategy { p u b l i c : v o i d DoAlgorithm (); }; Context
Design Patterns – part I 14/32 Observer Intent
I Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
Motivation
I A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects.
Applicability
I When an abstraction has two aspects, one dependent on the other. I When a change to one object requires changing others. I When an object should be able to notify other objects without making assumptions about who these objects are.
Design Patterns – part I 15/32 Observer
Figure: Structure
Design Patterns – part I 16/32 Observer
Participants
I Subject
I Observer
I ConcreteSubject
I ConcreteObserver
Collaborations
I ConcreteSubject notifies its observers whenever a change occurs that could make its observers’ state inconsistent with its own.
I After being informed of a change in the concrete subject, aConcreteObserver object may query the subject for information.
Design Patterns – part I 17/32 Observer
Consequences
I Abstract coupling between Subject and Observer.
I Support for broadcast communication.
I Unexpected updates.
Design Patterns – part I 18/32 Observer
Implementation
c l a s s S u b j e c t ; c l a s s O b s e r v e r { p u b l i c : v i r t u a l ˜ Observer(); v i r t u a l void Update(Subject ∗ theChangedSubject) = 0; p r o t e c t e d : Observer (); }; c l a s s S u b j e c t { p u b l i c : v i r t u a l ˜Subject (); v i r t u a l void Attach(Observer ∗ ); v i r t u a l void Detach(Observer ∗ ); v i r t u a l void N o t i f y ( ) ; p r o t e c t e d : S u b j e c t ( ) ; p r i v a t e : l i s t
Design Patterns – part I 19/32 Observer Implementation
v o i d Subject ::Attach (Observer ∗ o ) { observers .push back ( o ) ; } v o i d Subject ::Detach (Observer ∗ o ) { observers .remove(o); } v o i d Subject::Notify () { l i s t
c l a s s ClockTimer : p u b l i c S u b j e c t { p u b l i c : ClockTimer (); v i r t u a l int GetHour ( ) ; v i r t u a l int GetMinute (); v i r t u a l int GetSecond (); v o i d Tick ( ) ; };
v o i d ClockTimer::Tick () { // update internal time−keeping state //... N o t i f y ( ) ; }
Design Patterns – part I 20/32 Composite
Intent
I Compose objects into tree structures to represent part-whole hierarchies.
Motivation
I Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components.
Applicability
I you want to represent part-whole hierarchies of objects
I you want clients to be able to ignore the difference between compositions of objects and individual objects
Design Patterns – part I 21/32 Composite
Figure: Structure
Design Patterns – part I 22/32 Composite
Participants
I Component
I Leaf
I Komposite
I Client
Collaborations
I Clients use the Component class interface to interact with objects in the composite structure.
Design Patterns – part I 23/32 Composite
Consequences
I defines class hierarchies consisting of primitive objects and composite objects
I makes the client simple
I makes it easier to add new kinds of components
I can make your design overly general
Design Patterns – part I 24/32 Composite Implementation
c l a s s Composite ; c l a s s Component { p u b l i c : //... v i r t u a l Composite∗ GetComposite() { r e t u r n 0 ; } }; c l a s s Composite : p u b l i c Component { p u b l i c : v o i d Add(Component ∗ ); //... v i r t u a l Composite∗ GetComposite() { r e t u r n this ; } }; c l a s s L e a f : p u b l i c Component { //... }; Composite∗ aComposite = new Composite ; L e a f ∗ a L e a f = new L e a f ; Component∗ aComponent ; Composite∗ t e s t ; aComponent = aComposite; i f (test = aComponent−>GetComposite()) { t e s t −>Add ( new L e a f ) ; } aComponent = aLeaf; i f (test = aComponent−>GetComposite()) { t e s t −>Add ( new L e a f ) ; }
Design Patterns – part I 25/32 MVC – Model-View-Controller
Model-View-Controller:
I Includes design patterns. I We can name three groups of objects:
I model – application object, I view – screen representation of model, I controller – defines way how user interface reacts to user input.
Design Patterns – part I 26/32 Model-View-Controller
I Transfers traditional architecture of batch systems:
I input-calculations-output into graphical user interface applications:
I controller-model-view
Design Patterns – part I 27/32 Model-View-Controller
Figure: The organization of MVC
Design Patterns – part I 28/32 Model-View-Controller
Figure: Web application using the MVC pattern
Design Patterns – part I 29/32 Model-View-Controller
Scenario: User provides input into window: 1. Controller instructs model to store the text provided by the user. 2. Model notifies all views about change. 3. All views redraw itself. 4. During redraw all views ask model about the text provided by the user.
Design Patterns – part I 30/32 Model-View-Controller
Figure: Interaction diagram for MVC
Design Patterns – part I 31/32 Bibliography
I Gamma E. et al.: Design patterns: Elements of Reusable Object-Oriented Software
Design Patterns – part I 32/32