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 AStrategy> c l a s s Context f v o i d Operation() f theStrategy .DoAlgorithm(); g //... p r i v a t e : AStrategy theStrategy; g; c l a s s MyStrategy f p u b l i c : v o i d DoAlgorithm (); g; Context<MyStrategy> aContext ; 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 f 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 (); g; c l a s s S u b j e c t f 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 <O b s e r v e r∗> o b s e r v e r s ; g; Design Patterns – part I 19/32 Observer Implementation v o i d Subject ::Attach (Observer ∗ o ) f observers .push back ( o ) ; g v o i d Subject ::Detach (Observer ∗ o ) f observers .remove(o); g v o i d Subject::Notify () f l i s t <O b s e r v e r ∗>::iterator i; f o r ( i= observers.begin(); i!= observers.end(); ++i) f (∗ i)−>Update ( t h i s ); g g c l a s s ClockTimer : p u b l i c S u b j e c t f 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 ( ) ; g; v o i d ClockTimer::Tick () f // update internal time−keeping state //... N o t i f y ( ) ; g 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 f p u b l i c : //... v i r t u a l Composite∗ GetComposite() f r e t u r n 0 ; g g; c l a s s Composite : p u b l i c Component f p u b l i c : v o i d Add(Component ∗ ); //... v i r t u a l Composite∗ GetComposite() f r e t u r n this ; g g; c l a s s L e a f : p u b l i c Component f //... g; 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()) f t e s t −>Add ( new L e a f ) ; g aComponent = aLeaf; i f (test = aComponent−>GetComposite()) f t e s t −>Add ( new L e a f ) ; g Design Patterns – part I 25/32 MVC – Model-View-Controller Model-View-Controller: I Architectural pattern. 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.