Software Design Patterns Muhammad Nasir m.nasir@iiu.edu.pk

Contents What is a Design Pattern? Elements of the Design Pattern What design patterns are NOT Describing Design Patterns Types of Design Patterns When to use Design Patterns Benefits of Design Patterns Draw backs to Design Patterns How to Select a Design Pattern

What is a Design Pattern? “Design Pattern is a solution to a recurring design problem”. “Design patterns represent solutions to problems that arise when developing software within a particular context”. A design pattern is not a finished design that can be transformed directly into code.

“ 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 Context: City Planning and Building architectures

What is a Design Pattern? Patterns capture the static and dynamic structure and collaboration among key participants in software designs Especially good for resolving non-functional issues Patterns facilitate reuse of successful software architectures and designs.

What Makes it a Pattern? A Pattern must: Have a name and be referenced consistently Solve a problem and be useful Have a context and can describe where the solution can be used Recur in relevant situations Provide sufficient information to solve the problem

Elements of Design Patterns Design patterns have four essential elements: Pattern name Problem Solution Consequences

Pattern Name It represents: a design problem its solutions its consequences in a word or two Makes it possible for us to think of design solution at a higher level of abstraction “The Hardest part of programming is coming up with good variable [function, and type] names.”

Problem Explains the problem and its context Lists preconditions to apply the pattern

Solution Describes the elements that make up the Design Relationships Responsibilities Collaborations Abstract solution not concrete implementation i.e. UML Diagram

Consequences Results and trade-offs of applying the pattern Critical for: Evaluating design alternatives Understanding costs Understanding benefits of applying the pattern Includes the impacts of a pattern on a system’s: Flexibility Extensibility Portability

Design Patterns are NOT They are Not: Designs that can be encoded in classes and reused as (i.e., linked lists, hash tables) They are: “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”

Design Pattern Descriptions Name and Classification: Essence of pattern Intent: What it does, its rationale, its context Also Known A: Other well-known names Motivation: Scenario illustrates a design problem Applicability: Situations where pattern can be applied Structure: Class and interaction diagrams Participants: Objects/classes and their responsibilities Collaborations: How participants collaborate Consequences: Trade-offs and results Implementation: Pitfalls, hints, techniques, etc. Sample Code Known Uses: Examples of pattern in real systems Related Patterns: Closely related patterns

Types of Patterns Creational patterns: Structural patterns: Deal with creating, initializing, and configuring classes and objects Structural patterns: Deal Composition of classes or objects Implementation of Interfaces, classes and objects. Behavioural patterns: Behavioural patterns characterize the ways in which classes or objects interact. How they distribute responsibility

Creational Patterns Abstract Factory: Builder: Factory Method: Provide an interface for building related or dependant objects without specifying their concrete class. Builder: Separate the construction of a complex object from its representation so that same construction process can create different representations. Factory Method: Define an interface for creating an object, but let subclass decide which class to instantiate. Factory Method lets a class defer instantiation to subclass.

Creational Patterns (cont.) Prototype: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. Singleton: Ensure a class only has one instance, and provide a global point of access to it.

Structural Patterns Adapter: Bridge: Composite: Decorator: Convert the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn’t otherwise because of the incompatible interfaces. Bridge: Decouple an abstraction from its implementation so that the two can vary independently. Composite: Compose objects into tree structures to represent part-whole hierarchies. Composite lets client treat individual objects and compositions of objects uniformly. Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a higher-level interface that makes the subsystem easier to use.

Structural Patterns (cont.) Facade: Simplifies the interface for a subsystem Flyweight: Many fine-grained objects shared efficiently. Proxy: Provide a placeholder for another object to control access to it.

Behavioural Patterns Chain of Responsibility: Command: Iterator: Request delegated to the responsible service provider Command: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Iterator: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Interpreter: Language interpreter for a small grammar Mediator: Coordinates interactions between its associates Memento: Snapshot captures and restores object states privately

Behavioral Patterns (cont.) Observer: Dependents update automatically when subject changes State: Object whose behaviour depends on its state Strategy: Abstraction for selecting one of many algorithms Template Method: Algorithm with some steps supplied by a derived class Visitor: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Design Pattern Space Object Class Scope Behavioural Structural Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Abstract factory Builder Prototype Singleton Object Interpreter Template method Adapter (class) Factory method Class Scope Behavioural Structural Creational Purpose The first categorization criterion, called purpose, reflects what a pattern does. Patterns can have either creational, structural, or behavioral purpose. Creational patterns concern the process of object creation. Structural patterns deal with the composition of classes or objects. Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.

Categorization Terms Scope is the domain over which a pattern applies Class Scope: relationships between base classes and their subclasses (static semantics) Object Scope: relationships between peer objects Some patterns apply to both scopes. The second criterion, called scope, specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static—fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. So the only patterns labeled "class patterns" are those that focus on class relationships. Note that most patterns are in the Object scope.

When to Use Patterns Solutions to problems that recur with variations No need for reuse if problem only arises in one context Solutions that require several steps: Patterns can be an overhead if solution is a simple linear set of instructions When you want a state of the art solution Patterns are useful for someone who really wants a smart solution.

Benefits of Design Patterns Promotes Reusability of design solutions Helps in Documentation Capture Expert knowledge and design tradeoffs Helps in Communication Helps in transition to OO Technology

Drawbacks to Design Patterns Patterns do not lead to direct code reuse Patterns are deceptively simple Teams may suffer from pattern overload Patterns are validated by experience and discussion rather than by automated testing Integrating patterns into a software development is a human-intensive activity.

How to Select a Design Pattern Consider how design pattern solve design problems. Scan Intent/Purpose sections. Study pattern’s similarities and contrasts.

References Gama, Helm, Johnson, Vlissides, Design Patterns Elements of Reusable Object-Oriented Software, Addison Wesley, 1995 B. Cheng – Michigan State University