Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University April 10, 2006
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Related Documents
