Design Patterns a Presentation by Sascha Konrad 1

Design Patterns a Presentation by Sascha Konrad 1

Overview Introduction What Is a Design Pattern How to Describe Design Patterns How Design Patterns Solve Design Problems Designing for Change How to Select a Design Pattern Conclusion Two Examples 3 5 13 16 25 29 32 40 2

Design Patterns Sascha Konrad Introduction (1) Designing object-oriented software is hard, designing reusable object-oriented software is even harder Design should be specific to problem, but also general enough to address future problems and requirements Expert designers reuse solutions that have worked for them in the past Recurring patterns of classes and communicating objects exist in many object-oriented systems 3

Design Patterns Sascha Konrad Introduction (2) If details of previous problems and their solutions are known, then they could be reused Recording experience in software design for others to use Design patterns important and recurring design in objectoriented systems 4

Design Patterns Sascha Konrad What Is a Design Pattern (1) “Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice” Christopher Alexander, A Pattern Language, 1977 5

Design Patterns Sascha Konrad What Is a Design Pattern (2) A pattern has in general 4 essential elements: Pattern name Problem Solution Consequences 6

Design Patterns Sascha Konrad Pattern Name A handle used to describe a design problem, its solutions and its consequences in a word or two Increases design vocabulary Makes it possible to design at a higher level of abstraction Enhances communication But finding a good name is often hard 7

Design Patterns Sascha Konrad Problem Describes when to apply the pattern Explains the problem and its context Might describe specific design problems or class or object structures Sometimes contains a list of conditions that must be met before it makes sense to apply the pattern 8

Design Patterns Sascha Konrad Solution Describes the elements that make up the design, their relationships, responsibilities and collaborations Doesn’t describe a particular concrete design or implementation Abstract description of design problems and how the pattern solves it 9

Design Patterns Sascha Konrad Consequences Results and trade-offs of applying the pattern Critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern Includes the impacts of a pattern on a system’s flexibility, extensibility or portability 10

Design Patterns Sascha Konrad Design Patterns Are Not Designs that can be encoded in classes and reused as is (i.e. linked lists, hash tables) Complex domain-specific designs (for an entire application or subsystem) They are: “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” 11

Design Patterns Sascha Konrad Where Design Patterns Are Used Design patterns can be implemented in object-oriented programming languages rather than procedural languages. In procedural languages design patterns for Inheritance, Polymorphism and Encapsulation would be defined 12

Design Patterns Sascha Konrad How to Describe Design Patterns Graphical notation is not sufficient To reuse design decisions, alternatives and trade-offs that led to the decisions are important Concrete examples are also important 13

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

Design Patterns Sascha Konrad Classification Design patterns can be classified by two criteria: 1. Purpose What a pattern does (creational, structural or behavioral) 2. Scope Whether the pattern applies primarily to classes (static, compile-time) or to objects (dynamic, run-time) 15

Design Patterns Sascha Konrad How Design Patterns Solve Design Problems Design patterns solve many of the day-to-day problems object-oriented designers face, and in many different ways. Here are several of these problems and how design patterns solve them. 16

Design Patterns Sascha Konrad Finding Appropriate Objects Hard part of object-oriented design is decomposing a system into objects Encapsulation, granularity, dependency, flexibility, performance, Design Patterns help identifying less obvious abstractions and the objects that can capture them 17

Design Patterns Sascha Konrad Determining Object Granularity Objects can vary tremendously in size and number Design patterns address this also i.e. describing how to decompose an object into smaller objects 18

Design Patterns Sascha Konrad Specifying Object Interfaces An object’s interface characterizes the complete set of requests that can be sent to the object A type particular interface Subtypes inherit the interfaces of its super types Run-time association to an object and one of its operations is known as dynamic binding Polymorphism Design patterns help defining the interfaces by identifying the key elements and the kind of data that gets sent across an interface A design pattern might also tell what not to put in an interface 19

Design Patterns Sascha Konrad Specifying Object Implementations (1) An object’s implementation is defined by its class Objects are created by instantiating a class A subclass inherits the definition of all data and operations from the parentclass Abstract classes define common interfaces, but cannot be instantiated 20

Design Patterns Sascha Konrad Specifying Object Implementations (2) Class vs. Interface Inheritance: Distinction between class and type Many design patterns depend on this distinction Programming to an Interface, not an Implementation: There two benefits from manipulating objects solely in terms of the interface defined by abstract classes 1. clients remain unaware of the specific types they use, as long as the objects adhere to the interface that clients expect 2. Clients remain unaware of the classes that implement these objects, clients only know about the abstract class(es) defining the interface Creational Patterns assure, that the system is written in terms of interfaces, not implementations 21

Design Patterns Sascha Konrad Putting Reuse Mechanism to Work (1) Inheritance vs. Composition: Class inheritance white-box-reuse compile-time Class composition black-box-reuse run-time Favor object composition over class inheritance any object can be replaced at run-time by another as long as it has the same type Fewer implementation dependencies Object composition helps keeping each class encapsulated and focused on one task Disadvantage: More objects and the system behavior will depend on their relationships 22

Design Patterns Sascha Konrad Putting Reuse Mechanism to Work (2) Delegation: A way of making composition as powerful as inheritance A receiving object delegates operations to its delegate Easy to compose behaviors at run-time Disadvantage: Makes the software harder to understand It can make software more complicate than it simplifies Inheritance vs. Parameterized Types: Defining a type without specifying all other types it uses (i.e. templates in C ) Also a way to compose behavior in object-oriented systems 23

Design Patterns Sascha Konrad Relating Run-Time and CompileTime Structures An object-oriented program's run-time structure often bears little resemblance to its code structure code structure frozen at compile-time run-time structure consists of rapidly changing networks of communicating objects Aggregation an object is being part of another object Acquaintance an object merely knows of another object With Acquaintance much looser coupling of objects is possible Relationships between objects and their types must be designed with great care, because they determine how good or bad a run-time structure is Many design patterns capture the distinction between compile-time and run-time structures explicitly 24

Design Patterns Sascha Konrad Designing for Change The key for maximizing reuse lies in anticipating new requirements and in designing the system that they can evolve accordingly System design must take change into its account Redesign affects many parts of the software system Design patterns help assuring that a system can change in specific ways by providing designs that add more flexibility to software 25

Design Patterns Sascha Konrad Design Patterns in Application Programs In an application program usually internal reuse, maintainability and extension are high priorities Design patterns that reduce dependencies can increase internal reduce They can make a system more maintainable when they’re used to limit platform dependencies and to layer a system They enhance extensibility by showing how to extend class hierarchies and how to exploit object composition 26

Design Patterns Sascha Konrad Design Patterns in Toolkits A toolkit is a set of related and reusable classes designed to provide useful, general-purpose functionality They are the object-oriented equivalent of subroutine libraries Toolkit design is harder than application design because they have to work in many applications The toolkit writer doesn’t know what those applications will be or their special needs Avoid assumptions that can limit flexibility, applicability and effectiveness 27

Design Patterns Sascha Konrad Design Patterns in Frameworks A framework is a set of operating classes that make up a usable design for a special class of software It dictates the architecture of an application They emphasize design reuse over code reuse Applications can be built faster and have similar structures Applications are very dependent on the framework Design patterns and frameworks are very similar, but they differ in three major ways 1. Design patterns are more abstract then frameworks 2. Design patterns are smaller architectural elements than frameworks 3. Design patterns are less specialized than frameworks 28

Design Patterns Sascha Konrad How to Select a Design Pattern Depending on the catalogue used there are several approaches: Consider how design patterns solve design problems Scan intent section Study how patterns interrelate Study patterns of like purpose Examine a cause of redesign Consider what should be the variable in the design 29

Design Patterns Sascha Konrad How to Use a Design Pattern Once a design pattern is picked the design pattern could be applied: Read the pattern once through an overview Go back and study the structure, participants and collaboration sections Look at the sample code section to see a concrete example of the pattern in code Choose names for patterns participants that are meaningful in the application context Define the classes Define application-specific names for operations in the pattern Implement the operations to carry out the responsibilities in the pattern 30

Design Patterns Sascha Konrad How Not to Use a Design Pattern They should not be applied indiscriminately Often they achieve flexibility and variability by introducing additional levels of indirection They complicate design and cost performance A design pattern should only be applied when the flexibility it affords is actually needed The consequences sections are helpful when evaluating a pattern’s benefits and liabilities 31

Design Patterns Sascha Konrad Conclusion Cataloging design patterns is important, it gives standard names and definitions for the techniques we use If design patterns in software are not studied it will not be able to improve them or to come up with new ones 32

Design Patterns Sascha Konrad What to Expect from Design Patterns There are several ways design patterns can affect the way object-oriented software is designed: A common design vocabulary A documentation and learning aid An adjunct to existing methods A target for refactoring 33

Design Patterns Sascha Konrad A Common Design Vocabulary Computer scientists name and catalog algorithms and data structures, but often they don’t name other kinds of patterns Design patterns provide a common vocabulary to use to communicate, document and explore design alternatives They make a system less complex by making it possible to talk about it at a higher level of abstraction 34

Design Patterns Sascha Konrad A Documentation and Learning Aid People learning object-oriented programming often complain that systems use inheritance in convoluted ways and it is difficult to follow the control flow Many of the systems use design patterns, so they become easier to understand Design patterns also make designing software easier by providing solutions for common problems Describing a system in terms of the design patterns it uses makes it easier to understand, otherwise people have to reverse-engineer to unearth the patterns 35

Design Patterns Sascha Konrad An Adjunct to Existing Methods Object-oriented design methods are supposed to promote good design, but they haven’t been able to capture the experience of expert designers Design patterns provide a way to describe more of the “why” of a design and not just record the results of decisions Design patterns are especially useful in turning an analysis model into an implementation model 36

Design Patterns Sascha Konrad A Target for Refactoring (1) One problem in developing reusable software is that it often has to be reorganized or refactored, design patterns help determining how to reorganize a design and reduce the amount of refactoring Lifecycle of object-oriented software: 1. Prototyping Software is brought to life through rapid prototyping and incremental changes until it meets an initial set of requirements and reaches adolescence, the main kind of reuse is white-box-reuse 2. Expansionary The software goes through an expansionary phase to meet new requirements until it becomes too inflexible and arthritic 37

Design Patterns Sascha Konrad A Target for Refactoring (2) 3. Consolidation Software becomes more general, block-box-reuse replaces white-box-reuse This cycle is unavoidable, but using design patterns prevents later refactoring Refactoring Tearing apart classes into special- and general-purpose components, moving operations up or down the class hierarchy and rationalizing to reorganize software in the consolida38 tion phase

Design Patterns Sascha Konrad A Parting Thought “It is possible to make buildings by stringing together patterns, in a rather loose way. A building made like this, is an assembly of patterns. It is not dense. It is not profound. But it is also possible to put patterns together un such a way that many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound.” Christopher Alexander, A Pattern Language, 1977 39

Design Patterns Sascha Konrad Two Examples Two design patterns and an example how they could be used: 1. Singleton Ensure a class only has one instance and provide a global point of access to it 2. Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically 40

Design Patterns Sascha Konrad Singleton (1) It’s important for some classes to have exactly one instance The best solution is to make the class itself responsible for keeping track of its sole instance The class can ensure that no other instance can be created by intercepting requests to create new objects and it can provide a way to access the instance 41

Design Patterns Sascha Konrad Singleton (2) The following sheets show an implementation of a scheduler It was used to simulate parallelism in a system to avoid communication- and synchronization problems It activates specific methods of objects periodically Only one instance of the class must exist To ensure this the singleton pattern is used 42

Design Patterns Sascha Konrad Singleton (3) 43

Design Patterns Sascha Konrad Singleton (4) 44

Design Patterns Sascha Konrad Singleton (5) Declaration: 45

Design Patterns Sascha Konrad Singleton (6) The singleton pattern makes the sole instance a normal instance of Scheduler, but that class is written that only one instance can ever be created This is done be hiding the operation that creates the instance behind a static member function Through getInstance() the only instance of the class can be accessed 46

Design Patterns Sascha Konrad Observer (1) A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects The observer pattern describes how to establish these relationships The key objects are: Subject A subject may have any number of depending observers Observer Observers are notified when the subject undergoes a change of state and then they will query the subject to synchronize its states with the subject’s state 47

Design Patterns Sascha Konrad Observer (2) 48

Design Patterns Sascha Konrad Observer (3) An example: The class Room is observing the class ControlPanelFM If something is set in ControlPanelFM Room is informed through its updatefunction ControlPanelFM knows its observers because it provides the interface for attaching and detaching Observer objects 49

Design Patterns Sascha Konrad Observer (4) The observer pattern gives the possibility to vary subjects and observers independently Subjects can be reused without reusing the observers and vice versa Observers can be added without modifying the subjects Abstract coupling between subject and observers Support for broadcast communication But unexpected updates possible (a simple operation can cause a cascade of updates) 50