1. Design Pattern

2. Definition: A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

3. History: Elements of Reusable Object-Oriented Software was published in 1994 by the so-called "Gang of Four" (Gamma et al.), which is frequently abbreviated as "GOF". That same year, the first Pattern Languages of Programming Conference was held and the following year, the Portland Pattern Repository was set up for documentation of design patterns.

4. Elements: Pattern name: increases vocabulary of designers Problem: intent, context, when to apply Solution: UML-like structure, abstract code Consequences: results and tradeoffs 4

5. 5 Design Patterns Generally at a “higher level” of abstraction. Not about designs such as linked lists or hash tables. Generally descriptions of communicating objects and classes.

6. Types: Creational patterns: Deal with initializing and configuring classes and objects Structural patterns: Deal with decoupling interface and implementation of classes and objects Composition of classes or objects Behavioral patterns: Deal with dynamic interactions among societies of classes and objects How they distribute responsibility

7. Singleton Used to ensure that a class has only one instance. For example, one printer spooler object, one file system, one window manager, etc. One may use a global variable to access an object but it does not prevent one from creating more than one instance. Instead the class itself is made responsible for keeping track of its instance. It can thus ensure that no more than one instance is created.

8. 8 Singleton Structure Singleton static Instance() SingletonOp() GetSingletonData() static uniqueInstance singletonData return uniqueinstance

9. Singleton public class SingletonDemo { private static volatile SingletonDemo instance = null; private SingletonDemo() { } public static SingletonDemo getInstance() { if (instance == null) { synchronized (SingletonDemo.class){ if (instance == null) { instance = new SingletonDemo (); } return instance; }

10. 10 Observer Pattern Need to separate presentational aspects with the data, i.e. separate views and data. Classes defining application data and presentation can be reused. Change in one view automatically reflected in other views. Also, change in the application data is reflected in all views Defines one-to-many dependency amongst objects so that when one object changes its state, all its dependents are notified

11. 11 Observer Pattern A=10% B=40% C=30% D=20% Application data A B C D ADCB Relative Percentages Y10 40 30 20 X15 35 35 15 Z10 40 30 20 A B C D Change notification Requests, modifications

12. 12 When to use the Observer Pattern? When an abstraction has two aspects: one dependent on the other. Encapsulating these aspects in separate objects allows one to vary and reuse them independently. When a change to one object requires changing others and the number of objects to be changed is not known. When an object should be able to notify others without knowing who they are. Avoid tight coupling between objects.

13. 13 Observer Pattern: Consequences Abstract coupling between subject and observer. Subject has no knowledge of concrete observer classes. (What design principle is used?) Support for broadcast communication. A subject need not specify the receivers; all interested objects receive the notification. Unexpected updates: Observers need not be concerned about when then updates are to occur. They are not concerned about each other’s presence. In some cases this may lead to unwanted updates.

14. 14 Facade Pattern: Problem Client Classes Subsystem classes Need to communicate with

15. 15 Facade Pattern: Solution Client Classes Subsystem classes Facade

16. 16 Facade Pattern: Why and What? Need to provide a simple interface to many, often small, classes. But not necessarily to ALL classes of the subsystem. Façade provides a simple default view good enough for most clients. Facade decouples a subsystem from its clients. Subsystems often get complex as they evolve. A façade can be a single entry point to each subsystem level. This allows layering.

17. 17 Facade Pattern: Participants and Communication Clients communicate with subsystem classes by sending requests to façade. Façade forwards requests to the appropriate subsystem classes. Clients do not have direct access to subsystem classes. Participants: Façade and subsystem classes

18. 18 Facade Pattern: Benefits Promotes weak coupling between subsystem and its clients. Helps in layering the system. Helps eliminate circular dependencies. Shields clients from subsystem classes; reduces the number of objects that clients deal with.

19. 19 Abstract Factory: The Problem 1.Consider a user interface toolkit to support multiple look- and-feel standards. 2.For portability an application must not hard code its widgets for one look and feel. How to design the application so that incorporating new look and feel requirements will be easy?

20. 20 Abstract Factory Pattern: Solution 2.This class declares an interface to create different kinds of widgets. 1.Define an abstract WidgetFactory class. 3.There is one abstract class for each kind of widget and concrete subclasses implement widgets for different standards. 4.WidgetFactory offers an operation to return a new widget object for each abstract widget class. Clients call these operations to obtain instances of widgets without being aware of the concrete classes they use.

21. 21 Abstract Factory: Solution WidgetFactory CreateScrollbar() CreateWindow() WindowScrollBar WWidgetFactory MacWidgetFactory Client WWindowMacWindow MacScrollBarWScrollBar One for each standard.

22. 22 Abstract Factory Pattern: Participants and Communication AbstractFactory: Declares the interface for operations to create abstract product objects. ConcreteFactory: Implements the operations to create concrete product objects. AbstractProduct: Declares an interface for a type of product object. ConcreteProduct: Defines a product object to be created by the corresponding factory. Client: Uses only the interface declared by the abstractFactory and AbstractProduct classes.

23. Adapter Intent Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Wrap an existing class with a new interface. Impedance match an old component to a new system

24. Problem An "off the shelf" component offers compelling functionality that you would like to reuse, but its "view of the world" is not compatible with the philosophy and architecture of the system currently being developed.

26. Model-View-Controller Model : The core of the application. This maintains the state and data that the application represents. When significant changes occur in the model, it notifies all of its views Controller : The user interface presented to the user to manipulate the application. View : The user interface which displays information about the model to the user. Any object that needs information about the model needs to be a registered view with the model.

28. 28 The Model Most programs are supposed to do work, not just be “another pretty face” but there are some exceptions useful programs existed long before GUIs The Model is the part that does the work--it models the actual problem being solved The Model should be independent of both the Controller and the View But it provides services (methods) for them to use Independence gives flexibility, robustness

29. 29 The Controller The Controller decides what the model is to do Often, the user is put in control by means of a GUI in this case, the GUI and the Controller are often the same The Controller and the Model can almost always be separated (what to do versus how to do it) The design of the Controller depends on the Model The Model should not depend on the Controller

30. 30 The View Typically, the user has to be able to see, or view, what the program is doing The View shows what the Model is doing The View is a passive observer; it should not affect the model The Model should be independent of the View, but (but it can provide access methods) The View should not display what the Controller thinks is happening

31. 31 Combining Controller and View Sometimes the Controller and View are combined, especially in small programs Combining the Controller and View is appropriate if they are very interdependent The Model should still be independent Never mix Model code with GUI code!

32. 32 Separation of concerns As always, you want code independence The Model should not be contaminated with control code or display code The View should represent the Model as it really is, not some remembered status The Controller should talk to the Model and View, not manipulate them The Controller can set variables that the Model and View can read

33. The End ?