Upload
lamtuyen
View
217
Download
2
Embed Size (px)
Citation preview
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
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
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