Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

Transcription

1 Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University

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

3 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++;}

4 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

5 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

6 Software Design Patterns Language independent descriptions of design solutions A tested and well-known solution to a recurring design problem

7 Software Design Patterns Intent Capture design experiences from experts Reuse successful solutions to standard problems Bridge between OOAD and OOP

8 Software Design Patterns Expected results High degree of reuse Elegant systems Well tested solutions Flexibility

9 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

10 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

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

12 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

13 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

14 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

15 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

16 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

17 MVC Model user input Control View visual output A view reflects the state in the model The model does not know the view Why?

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 Design Pattern Classification GoF classified design patterns into three categories Creational Structural Behavioral

32 A Design Pattern Template Name and Classification Intent Also Known As Motivation Applicability Structure Collaborations Consequences Implementation Sample Code Known Uses Related Patterns Participants

33 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

34 Editor Design Editor Shape BoundingBox() CreateManipulator() TextView Circle BoundingBox() CreateManipulator() Text BoundingBox() CreateManipulator() GetExtent() GetOrigin()

35 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

36 Class Adapter Client Target Request() Adaptee SpecificRequest() Adapter Request() SpecificRequest()

37 Object Adapter Client Target Request() Adaptee SpecificRequest() adaptee Adapter Request() adaptee->specificrequest()

38 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

39 Adapter Related Patterns Bridge Decorator Proxy These will be presented on Monday

40 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

41 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

42 Conclusion Software Design Patterns gives Effective design Increased understanding Common vocabulary Stable systems Better reuse Automation

43 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

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

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

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