Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University 2005-04-07
Acronyms Object Oriented Analysis and Design (OOAD) Object Oriented Programming (OOD 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 nonmodifiable 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 Catalogues 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 Model user input Control View visual output A view reflects the state in the model The model does not know the view Why?
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 View 1 Model? 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 hart 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 Collaborations Consequences Implementation Sample Code Known Uses Related Patterns Participants
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 Editor Shape BoundingBox() CreateManipulator() TextView Circle BoundingBox() CreateManipulator() Text BoundingBox() CreateManipulator() GetExtent() GetOrigin()
Editor Design How can the system provided TextView class be reused by the graphical editor? Consider two solutions Class version of Adapter Object version of Adapter
Class Adapter Client Target Request() Adaptee SpecificRequest() Adapter Request() SpecificRequest()
Object Adapter Client Target Request() Adaptee SpecificRequest() adaptee Adapter Request() adaptee->specificrequest()
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 depentents 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