Design Patterns An Introduction

1. Design PatternsAn Introduction CMSC 432

2. Outline • In this lecture we’ll • have an introduction to design patterns from • Design Patterns - Elements of Reusable Object-Oriented Software by Gamma et al. • Other Sources • look at their presentation of design patterns • begin to look at the facade design pattern Design Patterns Introduction

3. What are Patterns? • Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander Design Patterns Introduction

4. What Patterns Aren’t • Patterns are a generalized concept, an idea formed in succinct manner, yet expressible in many different ways. They aren’t: • an exact solution • the basis of a code catalog Design Patterns Introduction

5. Introduction • Experienced OO designers will tell you that are reusable and flexible design is difficult to get right • Experienced designers know not to solve every problem from first principles • They use solutions that have worked for them in the past - they reuse design patterns • A design pattern captures expertise • Design patterns are not exact recipes or concrete designs Design Patterns Introduction

6. Why Patterns? • Design is a challenging task • Balancing concerns, e.g. performance, adaptability,reliability. • Defining components and their interrelationships. • Thus experienced designers: • Rarely start from first principles • Look for similarities to problems solved in the past. • Apply a working "handbook" of approaches • Patterns make expert knowledge widely available • Supports focusing on the truly distinctive design problems. • Aids design evaluation at higher level of abstraction • Provides a useful working vocabulary for design. Design Patterns Introduction

7. Levels of Patterns • Patterns occur at every level of development. • Code Idioms • Recurring control structure groupings. • Example: sentinel terminated loop. • System Level: Architectural styles • Recurring system level structures. • Example: layers (e.g., Internet protocols). • Example: client/server (e.g., World Wide Web). • Subsystem Level: Design patterns • Recurring tactical structures. • Example: iterators to process collections of objects. Design Patterns Introduction

8. Documenting Patterns • Motivation or context for a pattern • Patterns are discovered not invented • Prerequisites for use • Description of the program structure that the pattern will define • A list of the participants needed to complete a pattern • Consequences of using the pattern, both positive and negative • Examples of the pattern’s usage • Documented via a template Design Patterns Introduction

9. The Pattern Name • The pattern name • is a handle we can use to describe a design pattern its solution and consequences in just a few words • having a vocabulary for patterns is important because its a basis for communication amongst designers Design Patterns Introduction

10. The Problem Definition • The problem definition describes when to apply the problem • It explains the problem and its context • It might describe specific design problems such as how to represent a particular algorithm as a set of objects or describe a set of objects that leads to problems in reuse Design Patterns Introduction

11. The Solution • The solution describes the elements that make up the design, their relationships, responsibilities and collaborations • The solution doesn’t describe a particular concrete designer implementation instead it describes an abstract description of a design problem and how a generalarrangement of classes solves it. Design Patterns Introduction

12. The Consequences • The consequences are the results and tradeoffs in applying the pattern. • These consequences often involve time/space tradeoffs • They may also address implementation issues as well • Since reuse is often a factor in object oriented design the consequences of a pattern may include its impact on a system’s flexibility, extensibility or portability Design Patterns Introduction

13. An Example • The Model/View/Controller(MVC) triad of classes is used to build user interfaces in the Smalltalk-80 system. Looking at the design patterns inside MVC should help you see what is meant by the term pattern Design Patterns Introduction

14. Model View Controller • MVC consists of three kinds of objects • Model - the application object • View -its screen presentation • Controller - the way the user interface reacts to user input • Before MVC, these three were lumped together Design Patterns Introduction

15. MVC Continued • MVC decouples the view of an object with the object itself • The decoupling is enabled by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever a model’s data value changes, the model notifies the views that depend on it Design Patterns Introduction

16. More on MVC • When a view is notified of a change the view has an opportunity to update itself • the MVC approach lets you attach multiple views to an object • An additional consequence is that one may add views without altering the model itself Design Patterns Introduction

17. MVC from a Design Pattern Perspective • The MVC is itself a design pattern • There are also additional patterns to be discussed here • the MVC decouples the model from the view - the pattern that allows decoupling of objects so that changes to one can affect changes to any number of others without requiring the changed object to know the details of the affected object is called the Observer pattern Design Patterns Introduction

18. Other Design Patterns • We could think of the MVC as a design that lets us treat a composite view just like we treat one of its components. The MVC has three components but we treat it as an user interface system. • In like manner whenever we what to group objects and treat the group like an individual object we can use the Composite pattern. Design Patterns Introduction

19. The Facade Pattern • Intent • Provide a unified interface to a set of interfaces in a subsystem in a subsystem, the facade provides a higher level interface that makes the subsystem easier to use • A picture makes this concept easier to understand Design Patterns Introduction

20. The Facade Pattern Idea Facade Design Patterns Introduction

21. Motivation • Structuring a system into subsystems helps reduce complexity • A common design goal is to minimize the communication and dependencies between subsystems or at least isolate them • The face design pattern enables to do this Design Patterns Introduction

22. An example • Consider for example a programming environment that gives applications access to its compiler subsystem • This system contains classes such as a Scanner, Parser, programmed , BytecodeStream and ProgramNodeBuilder that implement the compiler Design Patterns Introduction

23. An example continued • Some clients need access to these lower level classes but in general most clients do not care about the details they only want to compile some code • To provide a higher level interface that can shield clients from these classes the compiler subsystem might also include a Compiler class which will provide a unified interface to the compilers functionality Design Patterns Introduction

24. The example continued • This Compiler class then acts as a facade • it offers clients a single simple interface to the compiler subsystem • it glues together the classes that implement the compiler’s functionality without hiding them completely • the compiler facade makes life easier for most programmers without hiding the lower-level functionality from the few that need it Design Patterns Introduction

25. Applicability of the Facade Pattern • Use the Facade pattern when • you want to provide a simple interface to a complicated subsystem - wrapping a subsystem with a facade make using it easier as the subsystem evolves • there are many dependencies between clients and the implementation classes in an abstraction Design Patterns Introduction

26. Applicability of the Facade Pattern Continued • Use the facade pattern when • You want to layer your subsystems. • Use a facade to define an entry point to each subsystem level. • If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades Design Patterns Introduction

27. Participants • Facade (Compiler) • knows which subsystem classes are responsible for a request • delegates client request to appropriate subsystem objects • subsystem classes (Scanner, Parser,etc) • implement subsystem functionality • handle work assigned by the Facade object • have no knowledge of the facade (i.e. keep no references to it) Design Patterns Introduction

28. Collaborations • Clients communicate with the subsystem by sending requests to the Facade objects which forwards the request to the appropriate subsystem object or objects • Facade may do more than delegation • Clients do not have access to the subsystem objects directly Design Patterns Introduction

29. Consequences • The Facade pattern offers the following benefits: • It shields clients from subsystem components reducing the number of objects that clients must deal with making the subsystem easier to use • It promotes weak coupling between subsystem and client. Often subsystems are strongly coupled making them hard to reuse and change Design Patterns Introduction

30. Consequences Continued • It does not prevent clients from using subsystem components if they need to do so. • It does control the use of the subsystem Design Patterns Introduction

31. References • http://www.swenet.org:8080/Overall/SoftDesign/DesignPatterns1/Patterns.pdf • Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ,Addison-Wesley Pub Co, 1995 1st Ed Design Patterns Introduction