Design Patterns

1. Design Patterns An Introduction By Ian M. Mac Donald

2. History • Difficulties in designing reusable object oriented software • Must be specific to problem, yet general enough to handle future problems • Reoccurring patterns appear in classes and communicating objects in many O.O. systems. • You may get “design déjá-vu”

3. What Was Needed • We need… to locate, explain and evaluate important reoccurring designs in object oriented system. • We need… a generation of successful designs and architectures that can be reused. • We need… a way to improve documentation and maintenance of existing systems.

4. Definition of a Design Pattern • In general, a design pattern describes a recurring problem and the core of its solution with the goal of creating reusable software. • A design pattern will “identify the participating classes and instances, their roles and collaborations, and the distribution of responsibilities”.

5. The Four Elements of a D.P. • Pattern Name – “handle” for a design problem, solutions and consequences. It is a good idea to keep this name down to one or two words.

6. The Four Elements of a D.P. • The Problem – When to apply the pattern. Explains problem and context, prerequisite conditions.

7. The Four Elements of a D.P. • The Solution – Elements that make up design, relationships, responsibilities, and collaborations. Does not give concrete, rather abstract description of problem and how a general arrangement of classes/objects can solve it.

8. The Four Elements of a D.P. • The Consequences – Results/trade-offs of applying the pattern. Ex: Space and time, language & implementation, impact on existing system.

9. Pattern Name and Classification Intent Also Known As Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample Code Known Users Related Patterns Attributes of a Design Pattern

10. Abstract Factory Adapter Bridge Chain of Responsibility Command Composite Decorator Façade Factory Method Flyweight Interpreter Iterator Mediator Memento Observer Prototype Proxy Singleton State Strategy Template Method Visitor Defined Design Patterns

11. Design Pattern Classifications • Creational Patterns • Concerned with the process of object creation • Structural Patterns • Concerned with the composition of classes or objects • Behavioral Patterns • Concerned with the characterizing the ways in which classes or objects interact and distribute responsibility.

12. Organization of Design Patterns • We organize our catalog of defined design patterns based on two criteria: • Purpose – That is, whether the pattern has a creational, structural, or behavioral purpose. • Scope – That is, whether the pattern applies primarily to objects or classes.

13. Design Pattern Classification

14. Deciding Which D.P. to Use • Consider how design patterns solve design problems • Scan the intent attributes of each design pattern • Study how patterns interrelate • Study patterns of like purpose • Examine a cause of redesign • Consider what should be variable in your design

15. How to Use a Design Pattern • Read a pattern once through for an overview • Study the structure • Look at the sample code • Choose names for pattern participants that are meaningful in the application context • Define the classes

16. How to Use a Design Pattern • Define application-specific names for operations in the pattern • Implement the operations to carry out the responsibilities and collaborations in the pattern

17. Design Pattern Example • Let’s look at the simplest design pattern in the catalog, the singleton.

18. Singleton Intent: Ensure a class has only one instance, and provide a global point of access to it. Motivation: It is important that some classes have only one instance. Ex: There can be many printers in a system, but there should only be one print spooler. Make the class itself responsible for keeping track of its sole instance Applicability: Use when there must be exactly one instance of a class, yet must be accessible to clients from a well known access point.

19. Singleton Structure:

20. Singleton Benefits: • Controlled access to sole instance. • Reduced name space – better than using global variables. • Permits a variable number of instances – if you change your mind and want to allow more than one instance of the Singleton class. Implementation: • Ensuring a unique instance. The design pattern will give you a lot of some sample code to illustrate how to implement.

21. Class Definition: class Singleton ( public: static Singleton* Instance(); protected: Singleton(); private: static Singleton* _instance; ); Corresponding Implementation: Singleton* Singleton::_instance = 0; Singleton* Singleton::Instance() { if (_instance == 0) { _instance = new Singleton; } return _instance; } Singleton

22. Sample Code: In addition to the sample code given in the implementation section, sample code for a practical implementation is given here. class MazeFactory ( public: static MazeFactory* Instance(); // existing interface goes here protected: MazeFactory(); private: static MazeFactory* _instance; ); MazeFactory* MazeFactory::_instance = 0; MazeFactory* MazeFactory::Instance() { if (_instance == 0) { _instance = new MazeFactory; } return _instance; } The sample code section will also demonstrate example subclasses. Singleton

23. Singleton Known Uses: Smalltalk-80[Par90] InterViews user interface toolkit[LCI+02] – used this design pattern to access the unique instance of its Session and WidgetKit classes. Related Patterns: Many patterns can be implemented by using the Singleton pattern. Example: Abstract Factory, Builder, and Prototype.