Idioms and Design Patterns

Martin SkogevallIDE, Mälardalen University

April 10, 2006

Acronyms

● Object Oriented Analysis and Design (OOAD)● Object Oriented Programming (OOP)● Software Design Patterns (SDP)● Gang of Four (GoF)● Graphical User Interface (GUI)● Object Oriented Languages (OOL)

Idioms

● Idioms exist in most languages– Often cultural expressions– Usually catches machine translators off-guard

● Examples– “It's raining cats and dogs”– while(*p) {*p++ = *q++;}

Abstract Idioms

● Immutable interfaces in Java– Java lacks the “const”-specifier for declaring non-

modifiable variables (immutable variables)– One standard solution is to expose interfaces that only

allows non-mutating operations

Idioms

● Idioms in a language can help expressing complex subtexts with simpler constructs– Other people understand what you are trying to

accomplish or describe when they recognize the idiom● Documenting idioms can thus help in

understanding expressions of code or speech● The idea behind a certain idiom can transcend

languages, but they are realized differently

Software Design Patterns

● Language independent descriptions of design solutions

● A tested and well-known solution to a recurring design problem

Software Design Patterns

● Intent– Capture design experiences from experts– Reuse successful solutions to standard problems– Bridge between OOAD and OOP

Software Design Patterns

● Expected results– High degree of reuse– Elegant systems– Well tested solutions– Flexibility

Software Design Patterns

● Solution– Abstractions...– Description of the problem in natural language– Solution to the problem in natural language with the

help of e.g. UML– Design Pattern Catalogs and Pattern Languages

Why bother with DP?

● Excellent OOD requires experience– Knowing OOD-methods by hand does not guarantee a

good design● OOD-methods usually concentrate on notation

– Will often just make for a good specification● DP gives a common vocabulary when describing

design decisions– Easier communication– Faster understanding of complex systems

History

● Christopher Alexander– The Timeless Way of Building, (1979)– A Pattern Language, (1977)

● SDP– OOPSLA – Using Pattern Languages for Object-

Oriented Programs, (1987)– GoF – Design Patterns, (1995)

The Gang of Four

● Design Patterns – Elements of Reusable Object-Oriented Software

● Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

● 1998 GoF received DrDobb Journal's Excellence in Programming Awards

● SDP bible

What is a Design Pattern?

● A description of communicating classes and/or objects which have been composed to give a generic solution to a recurring problem– Describes a solution to a recurring design problem– Description of how classes interact to accomplish the

task– Design Patterns have a relatively high level of

abstraction– Is a generic solution

Studying Design Patterns

● Studying DP is an effective way to learn OOD– Learn from experts' knowledge

● DP is still more art than science● To take full advantage of DP you need

– Prior experience of OO– Creativity

The Design Pattern Structure

● Name– A good name that reflects the design pattern's

functionality is very important– Not too specialized

● The problem● The solution● Consequences

Example – Model-View-Controller

● Name– Model-View-Controller (MVC)

● The Problem– Disconnect dependencies between logic and data to be

displayed from the code that displays the data. Also disconnect handling of user input from the data model.

● The Solution– MVC utilizes other DPs to achieve it's goal

MVC

● A view reflects the state in the model● The model does not know the view

– Why?

Model

Control Viewuser input visual output

MVC – The View

● How can the model notify the views when data is changed and still be unaware of the views?– Some kind of message dispatcher is needed– Fortunately, there is a design pattern that fits perfectly

?Model

View 1

View 2

View 3

MVC – The View

● The Observer Pattern– Define a one-to-many dependency between objects so

that when one object changes state, all its depentents are notified and updated automatically

● Decreases coupling between the model classes and the view classes

MVC – The Controller

● The controller handles user input and translates that into operations on the model– This makes it possible to change translations of user

input without modifying the model● The relation between the model and controller is

where another design pattern can be used

MVC – The Controller

● The Strategy Pattern– Define a family of algorithms, encapsulate each one,

and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

● Allows even for changes of translations during run-time– E.g. a sportscar simulator can either accept steering

input from a joystick or from the keyboard

MVC – Wrap-up

● The Model-View-Controller is a domain specific design pattern– It is used in GUI applications

● The MVC is built on other domain independent design patterns– Observer and Strategy

● Helps us achieving even more fundamental design patterns– Coupling and Cohesion

Common Errors in Designs

● Objects are created by explicit naming● Example

– Button *b = new MotifButton;● Problem

– The class describes a certain implementation● Solution

– Create instances indirectly– Abstract Factory, Factory Method, Prototype

Common Errors in Designs

● Dependencies on specific operations● Problem

– The target of a message is hard-coded● Solution

– Make it possible to delegate the message– Chain of Responsibility, Command

Common Errors in Designs

● Hardware/software dependencies● Problem

– The system becomes hard to port to other platforms● Solution

– Design platform independent code– Abstract Factory, Bridge

Common Errors in Designs

● Dependencies on object representation and implementation

● Problem– Clients knows how an object is represented

● Solution– Hide the information from clients– Abstract Factory, Bridge, Memento, Proxy

Common Errors in Designs

● Too strong coupling between classes/objects● Problem

– Hard to change and reuse these classes● Solution

– Use patterns that gives loose couplings– Abstract Factory, Bridge, Chain of Responsibility,

Command, Facade, Mediator, Observer

Common Errors in Designs

● Algorithm dependencies● Problem

– Algorithms can often change● Solution

– Isolate the algorithms in their own objects– Builder, Iterator, Strategy, Template Method, Visitor

Common Errors in Designs

● Extend functionality through inheritance● Problem

– Requires intimate knowledge of the superclasses● Solution

– Prefer composition or delegation– Bridge, Chain of Responsibility, Composite,

Decorator, Observer, Strategy

Common Errors in Designs

● Inability to change class interface and implementation (due to third party vendors, or legacy)

● Problem– Source code cannot be changed

● Solution– Some design patterns allow certain modifications– Adapter, Decorator, Visitor

Design Pattern Classification

● GoF classified design patterns into three categories– Creational– Structural– Behavioral

A Design Pattern Template

● Name and Classification

● Intent● Also Known As● Motivation● Applicability● Structure● Participants

● Collaborations● Consequences● Implementation● Sample Code● Known Uses● Related Patterns

Case Study – The Adapter Pattern

● Intent– To convert a class' interface so that incompatible

classes can cooperate● A.k.a Wrapper● Example – Graphics Editor

– Basic classes: line, circle, polygon and text– Abstraction: Graphical objects can draw themselves

and be manipulated by the user

Editor Design

EditorShapeBoundingBox()CreateManipulator()

CircleBoundingBox()CreateManipulator()

TextBoundingBox()CreateManipulator()

TextViewGetExtent()GetOrigin()

Editor Design

● How can the system-provided class TextView be reused by the graphical editor?

● Consider two solutions– Class version of Adapter– Object version of Adapter

Class Adapter

ClientTargetRequest()

AdapterRequest()

AdapteeSpecificRequest()

SpecificRequest()

Object Adapter

ClientTargetRequest()

AdapterRequest()

AdapteeSpecificRequest()

adaptee->SpecificRequest()

adaptee

Adapter - Consequences

● Class Adapter– Can only access functionality from one adaptee class– Methods are hard to shadow– Introduces only one object– No extra call-overhead

● Object Adapter– Can access functionality from a whole class hierarchy– Methods can easily be shadowed– Needs more manual labor to create

Adapter – Related Patterns

● Bridge● Decorator● Proxy● These will be presented on Monday

Design Patterns Requirements

● No special tools needed● A compiler for a OOL

– E.g. Java, C++, Ada 95, Smalltalk● Features needed except for classes and objects

– Inheritance– Polymorphism

● It is easier if the compiler supports these

Design Pattern Drawbacks

● When should DP not be used?● The flexibility introduced often relies on an extra

level of indirection– Complicates design– More overhead

● Study the section “Consequences” in the DP description to understand the common drawbacks of a certain DP

Conclusion

● Software Design Patterns gives– Effective design– Increased understanding– Common vocabulary– Stable systems– Better reuse– Automation

Pattern Libraries

● A lot of design patterns are utilized in different frameworks– These DP are also usually domain specific

● Loki is a C++ library with implemented design patterns– Alexei Alexandrescu, Modern C++ design– Relies heavily on templates– Only recently compilers are able to digest the library

Observer

– Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

Strategy

– Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

Command

– Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations