Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design...

Introduction to Design Patterns

Part 1

© Lethbridge/Laganière 2001 Chapter 6: Using design patterns 2

Patterns - Architectural

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…


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 architectural patterns

Done during detailed design work after architectural design is ‘solid.’

Design patterns are sometimes known as architectural patterns.


General Concepts of Design Patterns

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.


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.


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).


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.


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.


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

Pattern Context

Pattern NamesPatterns 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 aclass. (a class (really object!) that many processes may desireaccess 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.)



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.


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)

7.Proxy(GofF)

8.Information Expert (Expert) (Grasp Pattern)

9.Creator (Grasp Pattern)

10.Controller Pattern (Grasp Pattern)

Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design...

Documents

Transcript of Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design...