Design Patterns

Unit-1

Introduction
1.1What is a Design Pattern?

     Designing reusable object-oriented software is  harder.

·      Must find relevant objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships among them.

·      Design should be specific to the problem at hand but also general enough to address future problems and requirements.

·      Avoid redesign, or at least minimize it.

·      Expert designers reuse solutions that have worked for them in the past.

·      When they find a good solution, they use it again and again; consequently, you'll find recurring patterns of classes and communicating objects in many object-oriented systems.

·      These patterns solve specific design problems and make object-oriented designs more flexible, elegant, and ultimately reusable.

·      A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

·      Design patterns make it easier to reuse successful designs and architectures.

·      Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise re usability.

·      Design patterns help a designer get a design "right" faster.

·      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.

·      The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.

·  The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.

In general, a pattern has four essential elements:

1.  The pattern name

·      It is a handle we can use to describe a design problem, its solutions, and consequences in a word or two.

·      Naming a pattern immediately increases our design vocabulary.

·      It lets us design at a higher level of abstraction.

·  Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation.

·      It makes it easier to think about designs and to communicate them and their trade-offs to others.

2.  The problem

·      Describes when to apply the pattern.

·      It explains the problem and its context.

·      It might describe specific design problems such as how to represent algorithms as objects.

·      It might describe class or object structures that are symptomatic of an inflexible design.

3.  The solution

·  Describes the elements that make up the design, their relationships, responsibilities, and collaborations.

·      The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations.

·   The pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects) solves it.

4.  The consequences

·    Consequences  are the results and trade-offs of applying the pattern.

·      They are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern.

·      The consequences for software often concern space and time trade-offs.

·      They may address language and implementation issues as well.

·  The consequences of a pattern include its impact on a system's flexibility, extensibility, or portability.

·      Listing these consequences explicitly helps you understand and evaluate them.

1.2. Design Patterns in Smalltalk MVC

^·          The Model/View/Controller triad of classes is used to build user interfaces in Smalltalk.

^·          MVC consists of three kinds of objects.

                 ^o     Model:  

^§    Application object which carries data.
^o     View: 

^§    Screen presentation. i.e. Visualization of data that model contains.

                  ^o     Controller:

^§    The way the user interface reacts to user input.

^§    Acts on model and view.

^§    Controls data flow into model object and update view.

^§    Keeps model and view separately.

·         MVC decouples these objects to increase flexibility and reuse.

·         MVC decouples views and models by establishing a subscribe/notify protocol between them.

·         A view must ensure that its appearance must reflect the state of the model.

·         Whenever the model’s data changes, the model notifies views that depend on it.

·         In response, each view gets an opportunity to update itself.

^·          You can also create new views for a model without rewriting it.
^·          The below diagram shows a model and three views.

^·          The model contains some data values, and the views defining a spreadsheet, histogram, and pie chart display these data in various ways.

^·          The model communicates with it’s values change, and the views communicate with the model to access these values.

^·          Feature of MVC is that views can be nested.

1.3.Describing Design Patterns

·         Graphical notations may be used to describe design pattern.

·         Graphical notations, while important and useful, aren’t sufficient.

·    They capture the end product of the design process as relationships between classes and objects.

·      To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it.

·         By using a consistent format we describe the design pattern.

·         Each pattern is divided into sections according to the following template.
Pattern Name and Classification:

·  Pattern name and classification  conveys the essence of the pattern briefly and clearly, good name is vital, because it will become part of design vocabulary.

Intent:

·         A short statement answers the following questions.

·         What does the design pattern do?

·         What is its reason and purpose?

·         What particular design issue or problem does it address?

Also Known As:

·         Other well-known names for the pattern, if any.

Motivation:

·    A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem.

·         The scenario will help understand the more abstract description of the pattern that follows.

Applicability:

·         What are the situations in which the design patterns can be applied?

·         What are examples of the poor designs that the pattern can address?

·         How can recognize situations?
Structure:

·   Graphical representation of the classes in the pattern using a notation based on the object Modeling Technique (OMT).
Participants:

·         The classes and/or objects participating in the design pattern and their responsibilities.

Collaborations:

·         How the participants collaborate to carry out their responsibilities.
 Consequences:

·         How does the pattern support its objectives?

·         What is the trade-offs and result of using the pattern?

·         What aspect of the system structure does it let vary independently? Implementation:

·         What pitfalls, hints, or techniques should be aware of when implementing the pattern?

·         Are there language-specific issues?

Sample Code:

·         Code fragments that illustrate how might implement the pattern in c++ or Smalltalk.

Known Uses:

·         Examples of the pattern found in real systems. Related Patterns:

·         What design patterns are closely related to this one? What are the imp differences? With Which other patterns should this one be used?
Related Patterns:

·         What design patterns are closely related to this one?

·         What are the important differences?

·         With which other patterns should this one be used?

1.4.The Catalog of Design Patterns

The catalog contains 23 design patterns.

1.      Abstract Factory

·    Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
2.      Adapter

·         Convert the interface of a class into another interface clients expect.

·   Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
3.      Bridge

·         Decouple an abstraction from its implementation so that the two can vary independently.
4.      Builder

·   Separate the construction of a complex object from its representation so that the same construction process can create different representations.
5.      Chain of Responsibility

·   Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.

·      Chain the receiving objects and pass the request along the chain until an object handles it.
6.      Command

·   Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and     support  undo able operations.
7.      Composite

·     Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
8.      Decorator

·         Attach additional responsibilities to an object dynamically.

·         Decorators provide a flexible alternative to subclassing for extending functionality.
9.      Facade

·         Provide a unified interface to a set of interfaces in a subsystem.

·         Facade defines a higher-level interface that makes the subsystem easier to use.
10.  Factory Method

·         Define an interface for creating an object, but let sub classes decide which class to instantiate.
·         Factory Method lets a class defer instantiation to sub classes.
11.  Flyweight
·         Use sharing to support large numbers of fine-grained objects efficiently.
12.  Interpreter
·     Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
13.  Iterator

·    Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
14.  Mediator

·        Define an object that encapsulates how a set of objects interact.

·   Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

15.  Memento

·       Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
16.  Observer

·       Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
17.  Prototype

·       Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
18.  Proxy

·         Provide a surrogate or placeholder for another object to control access to it.

19.  Singleton

·         Ensure a class only has one instance, and provide a global point of access to it.
20.  State

·         Allow an object to alter its behavior when its internal state changes.

·         The object will appear to change its class.
21.  Strategy

·         Define a family of algorithms, encapsulate each one, and make them interchangeable.

·         Strategy lets the algorithm vary independently from clients that use it.
22.  Template Method

·         Define the skeleton of an algorithm in an operation, deferring some steps       to  sub classes.

·        Template Method lets sub classes  redefine certain steps of an algorithm without changing the algorithm's structure.

23.  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.

1.5.Organizing the Catalog

·           Design patterns vary in their granularity and level of abstraction.

·           We classify design patterns by two criteria.

o   Purpose - reflects what a pattern does. Patterns can have creational, structural, or behavioral purpose.

o   Scope - specifies whether the pattern applies primarily to classes or to objects.

		Purpose
		Creational	Structural	Behavioral
Scope	Class	Factory Method	Adapter	Interpreter Template Method
	Object	Abstract Factory Builder Prototype Singleton	Adapter Bridge Composite Decorator Façade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

·           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.

·           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.

·           Creational class patterns defer some part of object creation to subclasses.

·           Creational object patterns defer it to another object.

·           Structural class patterns use inheritance to compose classes.

·           Structural object patterns describe ways to assemble objects.

·           Behavioral class patterns use inheritance to describe algorithms and flow of control.

·           Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.

·           There are other ways to organize the patterns.

·           Some patterns are often used together.

·           Some patterns are alternatives.

·           Some patterns result in similar designs even though the patterns have different intents.

·           Another way to organize design patterns is according to how they reference each other in their "Related Patterns" sections.

1.6 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.

Finding Appropriate Objects

¾    Object-oriented programs are made up of objects.

¾    An object packages both data and the procedures (methods or operations) that operate on that data.

¾    An object performs an operation when it receives a request (or message) from a client.

¾    Requests are the only way to get an object to execute an operation.

¾    Operations are the only way to change an object's internal data.

¾    the object's internal state is said to be encapsulated;

¾    It cannot be accessed directly, and its representation is invisible from outside the object.

¾    The hard part about object-oriented design is decomposing a system into objects.

¾ The task is difficult because many factors come into play: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, and so on.

¾   They all influence the decomposition, often in conflicting ways.

¾  Design patterns help to identify less-obvious abstractions and the objects that can capture them.

Determining Object Granularity

¾    Objects can vary tremendously in size and number.

¾    They can represent everything down to the hardware or all the way up to entire applications.

¾    Design patterns address the issue that how to decide what should be an object?

¾    The Facade pattern describes how to represent complete subsystems as objects.

¾ Flyweight pattern describes how to support huge numbers of objects at the finest granularities.

¾    Other design patterns describe specific ways of decomposing an object into smaller objects.

Specifying Object Interfaces

Signature:

¾    Every operation declared by an object specifies the operation's name, parameters, and the operation's return value.

¾    This is known as the operation's signature.

Interface:

¾    The set of all signatures defined by an object's operations is called the interface to the object.

¾    An object's interface characterizes the complete set of requests that can be sent to the object.

¾    Any request that matches a signature in the object's interface may be sent to the object.
¾  Interfaces are fundamental in object-oriented systems.

¾    Objects are known only through their interfaces.

¾    There is no way to know anything about an object or to ask it to do anything without going through its interface.

¾    Two objects having different implementations can have identical interfaces.

¾    When a request is sent to an object, the particular operation that's performed depends on both the request and the receiving object.

¾    Different objects that support identical requests may have different implementations of the operations.

Type:

¾    A type is a name used to denote a particular interface.

¾    An object may have many types, and widely different objects can share a type.

¾    Part of an object's interface may be characterized by one type, and other parts by other types.

¾    Two objects of the same type need only share parts of their interfaces.

¾    Interfaces can contain other interfaces as subsets.

¾    A type is a sub type of another if its interface contains the interface of its super type.

¾    A sub type inheriting the interface of its super type.

Dynamic binding:

¾    The run-time association of a request to an object and one of its operations is known as dynamic binding.

¾    Issuing a request doesn't commit you to a particular implementation until run-time.

¾    Lets you substitute objects that have identical interfaces for each other at run-time.

Polymorphism:

¾    It lets a client object make few assumptions about other objects beyond supporting a particular interface.

¾    Polymorphism simplifies the definitions of clients, decouples objects from each other, and lets them vary their relationships to each other at run-time.

¾    Design patterns help you define interfaces by identifying their key elements and the kinds of data that get sent across an interface.

¾    Design patterns tell you what not to put in the interface.

¾    Design patterns specify relationships between interfaces.

Specifying Object Implementations

Class:

¾    An object's implementation is defined by its class.

¾    The class specifies the object's internal data and the operations the object can perform.

¾    Objects are created by instantiating a class.

¾    The object is said to be an instance of the class.

¾    The process of instantiating a class allocates storage for the object's internal data and associates the operations with these data.

¾    Many similar instances of an object can be created by instantiating a class.

¾    New classes can be defined in terms of existing classes using class inheritance.

¾    When a subclass inherits from a parent class, it includes the definitions of all the data and operations that the parent class defines.

¾    Objects that are instances of the subclass will contain all data defined by the subclass and its parent classes, and perform all operations defined by this subclass and its parents.

Abstract class and Concrete Class

¾  An abstract class is one whose main purpose is to define a common interface for its subclasses.

¾  An abstract class will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated.

¾  The operations that an abstract class declares but doesn't implement are called abstract operations.

¾    Classes that aren't abstract are called concrete classes.

¾    Subclasses can refine and redefine behaviors of their parent classes.

¾    A class may override an operation defined by its parent class.

Class inheritance

¾    Class inheritance lets you define classes simply by extending other classes, making it easy to define families of objects having related functionality.

Mixin class

¾    A mixin class is a class that's intended to provide an optional interface or functionality to other classes. It's similar to an abstract class in that it's not intended to be instantiated. Mixin classes require multiple inheritances.

Class versus Interface Inheritance

Object's class vs. its type:

¾    An object's class defines how the object is implemented.

¾    The class defines the object's internal state and the implementation of its operations.

¾    An object's type only refers to its interface—the set of requests to which it can respond.

¾    An object can have many types, and objects of different classes can have the same type.

Class inheritance vs. Interface inheritance:

¾ Class inheritance defines an object's implementation in terms of another object's implementation

¾    It’s a mechanism for code and representation sharing.

¾    Interface inheritance (or subtyping) describes when an object can be used in place of another.

Programming to an Interface, not an Implementation

¾    Class inheritance is a mechanism for extending an application's functionality by reusing functionality in parent classes.

¾    It lets you define a new kind of object rapidly without new implementations.

¾    When inheritance is used properly, all classes derived from an abstract class will share its interface.

¾    This implies that a subclass adds or overrides operations and does not hide operations of the parent class.

¾    All subclasses can then respond to the requests in the interface of this abstract class, making them all subtypes of the abstract class.

¾    There are two benefits to manipulating objects in terms of the interface defined by abstract classes:

1.     Clients remain unaware of the specific types of objects 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.

¾    It reduces implementation dependencies between subsystems

¾    Don't declare variables to be instances of particular concrete classes.

¾    Instead, commit only to an interface defined by an abstract class.

Putting Reuse Mechanisms to Work

¾    Most people can understand concepts like objects, interfaces, classes, and inheritance.

¾    The challenge lies in applying them to build flexible, reusable software, and design patterns.

Class Inheritance versus Object Composition

¾    The two most common techniques for reusing functionality in object-oriented systems are class inheritance and object composition.
¾  Class inheritance lets you define the implementation of one class in terms of another's.

¾    Reuse by sub classing is often referred to as white-box reuse.

¾    Internals of parent classes are often visible to sub classes.

¾    Object composition is an alternative to class inheritance.

¾    New functionality is obtained by composing objects to get more complex functionality.

¾    Reuse by Object composition is called black-box reuse.

¾    no internal details of objects are visible.

Advantage and Disadvantages Class inheritance

¾    defined statically at compile-time and is straightforward to use

¾    Supported directly by the programming language.

¾    Easier to modify the implementation being reused.

¾ Can’t change the implementations inherited from parent classes at run-time, because inheritance is defined at compile-time.

¾    Parent classes often define at least part of their subclasses' physical representation.

¾    breaks encapsulation

¾    Any change in the parent's implementation will force the subclass to change.

¾  The parent class must be rewritten if inherited implementation is not appropriate for new problem domains.

¾    Limits flexibility and re usability.

Advantage and Disadvantages of Object composition

¾    Defined dynamically at run-time.

¾    Don’t break encapsulation.

¾    Any object can be replaced at run-time by another as long as it has the same type.

¾    Fewer implementation dependencies.

¾    Object composition helps to keep each class encapsulated and focused on one task.

Delegation

¾    Delegation is a way of making composition for reuse.

¾    In delegation, two objects are involved in handling a request.

¾    A receiving object delegates operations to its delegate.

¾    The receiver passes itself to the delegate to let the delegated operation refer to the receiver.

¾  For example, instead of making class Window a subclass of Rectangle, the Window class might reuse the behavior of Rectangle by keeping a Rectangle instance variable and delegating.
¾ Instead of a Window being a Rectangle, it would have a Rectangle. Window must now forward requests to its Rectangle instance explicitly.

¾    The diagram depicts the Window class delegating its Area operation to a Rectangle instance.

¾    A plain arrowhead line indicates that a class keeps a reference to an instance of another class. The reference has an optional name, "rectangle" in this case.

Advantage and disadvantage of delegation

¾    Easy to compose behaviors at run-time and to change the way they're composed.

¾    Dynamic, highly parameterized software is harder to understand than more static software.

¾    Run-time inefficiencies.

¾    Good design choice only when it simplifies complexity.

¾    Works best when it's used in highly stylized ways—that is, in standard patterns.

Inheritance versus Parameterized Types

Parameterized Types

¾    Another technique for reusing functionality.

¾    Also known as generics (Ada, Eiffel) and templates (C++).

¾    Lets you define a type without specifying all the other types it uses.

¾    Unspecified types are supplied as parameters at the point of use.

¾    Parameterized types give us a way (in addition to class inheritance and object composition) to compose behavior in object-oriented systems.

¾    Many designs can be implemented using any of these three techniques.

1.    An operation implemented by subclasses (an application of Template Method)

2.      The responsibility of an object that's passed to the sorting routine (Strategy)

3.        An argument of a C++ template or Ada generic that specifies the name of the function to call to compare the elements.

Object composition vs.  Inheritance vs. Parameterized types

¾  Object composition lets you change the behavior being composed at run-time, but it also requires indirection and can be less efficient.

¾  Inheritance lets you provide default implementations for operations and lets subclasses override them.

¾    Parameterized types let you change the types that a class can use.

Relating Run-Time and Compile-Time Structures

¾    An object-oriented program's run-time structure often bears little resemblance to its code structure.

¾  The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships.

¾  A program's run-time structure consists of rapidly changing networks of communicating objects.

Object aggregation vs. acquaintance

¾    Object aggregation and acquaintance tells us how differently they manifest themselves at compile- and run-times.

¾    Aggregation and acquaintance are often implemented in the same way.
¾  Aggregation - An object having or being part of another object.

¾    An aggregate object and its owner have identical lifetimes.

¾    Aggregation relationships are more permanent than acquaintance.

¾    Acquaintance – An object merely knows of another object.

¾    Sometimes acquaintance is called "association" or the "using" relationship.

¾    Acquainted objects may request operations of each other, but they aren't responsible for each other.

¾    Acquaintance is a weaker relationship than aggregation.

¾    Suggests much looser coupling between objects.

¾    Acquaintances are made and remade more frequently.

¾    Acquaintances are more dynamic.

¾    Hence, code won't reveal everything about how a system will work.

¾    System's run-time structure must be imposed by the designer than the language.

Designing for Change

¾  A design that doesn't take change into account risks major redesign in the future. Those changes might involve class redefinition and reimplementation, client modification, and retesting.

¾   Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

¾  Design patterns help you avoid redesign by ensuring that a system can change in specific ways.

¾    Each design pattern lets some aspect of system structure vary independently of other aspects.

Common causes of redesign:

1.         Creating an object by specifying a class explicitly.

2.         Dependence on specific operations.

3.         Dependence on hardware and software platform

4.         Dependence on object representations or implementations.

5.         Algorithmic dependencies.

6.         Tight coupling. Classes that are tightly coupled are hard to reuse.

7.         Extending functionality by subclassing.

8.         Inability to alter classes conveniently.

The role design patterns in the development of three broad classes of software: application programs, toolkits, and frameworks.

Application Programs

¾    Internal reuse, maintainability, and extension are high priorities.

¾    Design patterns that reduce dependencies can increase internal reuse.

¾    Looser coupling helps that one class of object can cooperate with several others.

¾    Design patterns make an application more maintainable when they're used to limit platform dependencies and to layer a system.

¾    Enhances extensibility by showing how to extend class hierarchies and how to exploit object composition.

¾    Reduced coupling enhances extensibility.

¾    Extending a class in isolation is easier if the class doesn't depend on other classes.

Toolkits

¾    A toolkit is a set of related and reusable classes designed to provide general-purpose functionality.

¾    Toolkits don't impose a particular design on your application

¾    They provide functionality that helps the application do its job.

¾    They avoid recoding common functionality.

¾    Toolkits emphasize code reuse.

¾    Design is harder than application design.

Frameworks

¾  A framework is a set of cooperating classes that make up a reusable design for a specific class of software.

¾  Framework can be customized to a particular application by creating application-specific subclasses of abstract classes.

¾    Framework dictates the architecture of your application.

¾ So that the application designer/implementer, can concentrate on the specifics of your application.

¾    The framework captures the design decisions that are common to its application domain.

¾    Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately.

¾  When you use a toolkit you write the main body of the application and call the code you want to reuse.

¾    When you use a framework, you reuse the main body and write the code it calls.

Advantages of framework

¾    Building applications faster if the applications have similar structures.

¾    Easier to maintain

¾    More consistent to their users.

The design issues are most critical to framework design.

¾    A framework that addresses design issues using design patterns is far more likely to achieve high levels of design and code reuse than one that doesn't.

¾    Mature frameworks usually incorporate several design patterns.

¾   The patterns help make the framework's architecture suitable to many different applications without redesign.

¾    People who know the patterns gain insight into the framework faster.

¾  Even people who don't know the patterns can benefit from the structure they lend to the framework's documentation.

¾   Enhancing documentation is important for all types of software, but it's particularly important for frameworks.

Differences design patterns and frameworks:

1.         Design patterns are more abstract than frameworks.

2.         Design patterns are smaller architectural elements than frameworks.

3.         Design patterns are less specialized than frameworks. 

How to Select a Design Pattern

·         It might be hard to find the one that addresses a particular design problem.

·         Several different approaches to find the design pattern that's right for the problem:

1.        Consider how design patterns solve design problems.

·    It discusses how design patterns help you find appropriate objects, determine object granularity, specify object interfaces, and several other ways in which design patterns solve design problems.

2.        Scan Intent sections.

· Read through each pattern's intent to find one or more that sound relevant to your problem.

3.        Study how patterns interrelate.

·   Studying these relationships between design patterns graphically can help direct to the right pattern or group of patterns.

4.        Study patterns of like purpose.

·         The catalog has three chapters (creational, structural, and behavioral patterns).

·         Each chapter starts off with introductory comments on the patterns and concludes with a section that compares and contrasts them.

·         These sections give you insight into the similarities and differences between patterns of like purpose.

5.        Examine a cause of redesign.

·         Look at the causes of redesign to see if your problem involves one or more of them.

·         Then look at the patterns that help you avoid the causes of redesign.

6.        Consider what should be variable in your design.

·      Instead of considering what might force a change to a design, consider what you want to be able to change without redesign.

·   The focus here is on encapsulating the concept that varies a theme of many design patterns.

How to Use a Design Pattern

A step-by-step approach to applying a design pattern effectively, once a design pattern is picked:

1.             Read the pattern once through for an overview.

·   Pay particular attention to the Applicability and Consequences sections to ensure the pattern is right for your problem.

2.             Go back and study the Structure, Participants, and Collaborations sections.

·      Make sure you understand the classes and objects in the pattern and how they relate to one another.

3.             Look at the Sample Code section to see a concrete example of the pattern in code.

·   Studying the code helps you learn how to implement the pattern.

4.             Choose names for pattern participants that are meaningful in the application context.

·   The names for participants in design patterns are usually too abstract to appear directly in an application.

·     It’s useful to incorporate the participant name into the name that appears in the application.

·      That helps make the pattern more explicit in the implementation.

·   For example, if you use the Strategy pattern for a text compositing algorithm, then you might have classes SimpleLayoutStrategy or TeXLayoutStrategy.

5.             Define the classes.

·         Declare their interfaces, establish their inheritance relationships, and define the instance variables that represent data and object references.

·         Identify existing classes in your application that the pattern will affect, and modify them accordingly.

6.             Define application-specific names for operations in the pattern.

·         The names generally depend on the application.

·         Use the responsibilities and collaborations associated with each operation as a guide.

·     Be consistent in your naming conventions. For example, you might use the "Create-" prefix consistently to denote a factory method.

7.             Implement the operations to carry out the responsibilities and collaborations in the pattern.

·         The Implementation section offers hints to guide you in the implementation.

·         The examples in the Sample Code section can help as well.

How not to use them:

·             Design patterns should not be applied indiscriminately.

·        Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance.

·              A design pattern should only be applied when the flexibility it affords is actually needed.

·              The Consequences sections are most helpful when evaluating a pattern's benefits and liabilities.