Introduction to Design Patterns Part 1

1. Introduction to Design Patterns Part 1

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

3. Patterns – Design • 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 architecturalpatterns • Done during detailed design work after architectural design is ‘solid.’ • Design patterns are sometimes known as architectural patterns. Chapter 6: Using design patterns

4. General Concepts of Design Patterns • Design Patterns are groups of objects (and their relationships) designed to supporta ‘good object design’ • What is ‘good object design?’ • design that yields highcohesion of our objects, • design that has lowcoupling 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. Chapter 6: Using design patterns

5. 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 object-oriented system, not merely the drawing of domain model diagrams, package diagrams, etc. Chapter 6: Using design patterns

6. 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 (abstraction- • occurrence, 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). Chapter 6: Using design patterns

7. What Design Patterns are All About • The recurring aspects of designs are called design patterns. •  A pattern is the outline of a reusable solutionto a generalproblem encountered in a particularcontext • 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. Chapter 6: Using design patterns

8. 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. Chapter 6: Using design patterns

9. 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 Chapter 6: Using design patterns

10. 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 singleinstance 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. 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.) Chapter 6: Using design patterns

11. Categories of Design Patterns • We will study several of the most often used patterns – GRASP Patterns, and • Gang of Four (GoF) 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. Chapter 6: Using design patterns

12. We will look at: • Gang of Four (GoF) Patterns • Grasp Patterns • Others. • Here are some (not in any particular order): • 1. Abstract-Occurrence • 2. Singleton(GofF) • 3. Observer(GofF) • 4. Delegation • 5. Adapter(GofF) • 6. Façade (GofF) • Proxy(GofF) • Information Expert (Expert) (Grasp Pattern) • Creator (Grasp Pattern) • Controller Pattern (Grasp Pattern) Chapter 6: Using design patterns