Introduction to Design Patterns Part 1 Patterns Architectural

Introduction to Design Patterns Part 1

Patterns - Architectural Patterns: Related to large-scale and coarse-grained design; Typically applied during the early iterations (the elaboration phase) when the major structures and connections are established. Examples: pipe and filter; MVC; Client-Server; Transaction, Broker, others… © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 2

Patterns – Design Patterns: Related to the small and medium-scale design of objects and frameworks. Applicable to designing a solution for connecting the large scale elements defined via architectural patterns Done during detailed design work after architectural design is ‘solid. ’ Design patterns are sometimes known as architectural patterns. Chapter 6: Using design patterns © Lethbridge/Laganière 2001 3

General Concepts of Design Patterns are groups of objects (and their relationships) designed to support a ‘good object design’ What is ‘good object design? ’ design that yields high cohesion of our objects, design that has low coupling between our objects, which, among other things, fosters more likely reuse It is one thing to create an object…it is quite another to create the right object for the right situation. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 4

Object Design – Not a Simple Undertaking! All design involves making decisions, and design is a decision-making activity Good object design involves the assignment of object responsibilities. There are patterns or groupings of objects that work together to accommodate commonly needed activities / functions that subscribe to accepted principles of good design. Deciding what methods belong where and how objects interact (their relationships) is critically important and NOT trivial. All this is really at the heart of what it means to develop an objectoriented system, not merely the drawing of domain model diagrams, package diagrams, etc. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 5

Preview: What Design Patterns are All About • Want to look at more class diagrams – static. • But we want to look at recurring groupings of classes that are regularly used to address common problems. • Want to take advantage of experiences of others and create a better, more resilient design. • Want to use (note the categories of common problems) Patterns that assist us in separating concerns (abstractionoccurrence, observer, player-role); Patterns used to better create class hierarchies of instances; Patterns in which one method simply calls another method in another class (have you seen this? ? ); Patterns where you use delegation to gain access to facilities in one or more other classes (Adaptor, Façade, Proxy patterns); Patterns that help protect other objects from unanticipated access (immutable and read-only interfaces). © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 6

What Design Patterns are All About The recurring aspects of designs are called design patterns. • A pattern is the outline of a reusable solution to a general problem encountered in a particular context • Many of them have been systematically documented for all software developers to use • A good pattern should —Be as general as possible —Contain a solution that has been proven to effectively solve the problem in the indicated context. Studying patterns is an effective way to learn from the experience of others We will look at several. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 7

Pattern Description Parameters Context: • The general situation in which the pattern applies Problem: —A short sentence or two raising the main difficulty. Forces: • The issues or concerns to consider when solving the problem Solution: • The recommended way to solve the problem in the given context. —‘to balance the forces’ Antipatterns: (Optional) • Solutions that are inferior or do not work in this context. Related patterns: (Optional) • Patterns that are similar to this pattern. References: • Who developed or inspired the pattern. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 8

Pattern Context Remember: our patterns define a relation among: a certain context a problem a solution • Here again, naming a pattern is using an abstraction of the details of that pattern • Patterns represent well-known knowledge • Really documents common practice • Patterns should be in the public domain • Patterns need to be written for the public good. • We are looking at certain arrangements of classes and relationships among classes that provide better design and/or more flexibility in addressing common design issues © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 9

Pattern Names Patterns have names and the names are ‘suggestive’ of what function they address. Their names can be used in our vocabulary to ‘communicate design intentions. ’ The Façade Pattern, can be used to provide the interface from one layer to the next… Singleton Pattern – to ensure global access to a single instance of a class. (a class (really object!) that many processes may desire access to: a monitor? ) More Design Patterns: Information Expert (Expert); Adaptor, Creator, Observer, Low Coupling, High Cohesion, Controller; etc. Design Patterns are often organized into different categories too. (Most of these notes from the first two lectures on Design Patterns are taken directly from Larman’s text. ) © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 10

Categories of Design Patterns We will study several of the most often used patterns – GRASP Patterns, and Gang of Four (Go. F) Patterns Others too. You will note you may be already doing some of these things. You may now see more rationale and more formal reasoning In all cases, the patterns will be most helpful as we strive to design objects and groupings of objects to accommodate common issues. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 11

We will look at: Gang of Four (Go. F) Patterns Grasp Patterns Others. Here are some (not in any particular order): 1. Abstract-Occurrence 2. Singleton(Gof. F) 3. Observer(Gof. F) 4. Delegation 5. Adapter(Gof. F) 6. Façade (Gof. F) 7. Proxy(Gof. F) 8. Information Expert (Expert) (Grasp Pattern) 9. Creator (Grasp Pattern) 10. Controller Pattern (Grasp Pattern) © Lethbridge/Laganière 2001 Chapter 6: Using design patterns 12