Introduction

What is a design Pattern ?

• Design patterns make it easier to reuse successful designs and architectures.
• A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities

• Design patterns help you define interfaces by identifying their key elements and the kinds of data that get sent across an interface. A design pattern might also tell you what not to put in the interface.
• Design patterns also specify relationships between interfaces. In particular, they often require some classes to have similar interfaces, or they place constraints on the interfaces of some classes.
• 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 names of abstract classes appear in slanted type to distinguish them from concrete classes.[for the notations section].

Design Principles

• Programming to an an interface, not an implementation
  • implementation reuse is only half the story. Inheritance's ability to define families of objects with identical interfaces (usually by inheriting from an abstract class) is also important. Why? Because polymorphism depends on it.
  • There are two benefits to manipulating objects solely 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.

  • This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design: Program to an interface, not an implementation.
• Inheritance versus Composition
  • Inheritance is “compile time“ and white-box. The details of parent are visible to sub-classes.
    • It is easier to use and modification of reused implementation is easier
    • "inheritance breaks encapsulation" . The implementation of a subclass becomes so bound up with the implementation of its parent class that any change in the parent's implementation will force the subclass to change.
  • Composition or assembly is “run-time” by objects acquiring reference to other objects.
    • All communications happen only through defined interfaces to encapsulation is better preserved.
    • Composition requires objects to respect each others' interfaces, which in turn requires carefully designed interfaces that don't stop you from using one object with many others.
    • Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters
    • However, a design based on object composition will have more objects (if fewer classes), and the system's behavior will depend on their interrelationships instead of being defined in one class.
    • Reuse by inheritance makes it easier to make new components that can be composed with old ones.

  Hence the principle:

  Favor object composition over class inheritance [ie prefer ‘have’ relation over ‘type of’ relation]

• Delegation
  • Delegation is a way of making composition as powerful for reuse as inheritance. In delegation, two objects are involved in handling a request: a receiving object delegates operations to its delegate. This is analogous to subclasses deferring requests to parent classes. The call however is explicit [instead of through inheritance.
  • The receiver passes itself to the delegate to let the delegated operation refer to the receiver.
  • The main advantage of delegation is that it makes it easy to compose behaviors at run-time and to change the way they're composed.
  • Delegation has a disadvantage it shares with other techniques that make software more flexible through object composition: Dynamic, highly parameterized software is harder to understand than more static software. There are also run-time inefficiencies, but the human inefficiencies are more important in the long run.
  • Delegation is a good design choice only when it simplifies more than it complicates.
• Inheritance versus Parameterized Types
  • Parameterized type is also called generics. or templates Recall class parameterization in c++/java.
  • Parameterized types let you change the types that a class can use. But neither inheritance nor parameterized types can change at run-time

What is a framework ?

The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, 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.

Design Aspects that design pattern let you vary ?


• Design for changes
  • Encapsulate the concept that varies
• Well-designed object-oriented systems are just like this – they have multiple patterns embedded in them – but not because their designers necessarily thought in these terms. Composition at the pattern level rather than the class or object levels lets us achieve the same synergy with greater ease.
• Design Pattern as aid in identifying targets for Refactoring
  • In developing reusable software we have to often reorganize or refactor. Design patterns help you determine how to reorganize a design, and they can reduce the amount of refactoring you need to do later.
  • The lifecycle of object-oriented software has several phases. Brian Foote identifies these phases as the prototyping, expansionary, and consolidating phases.
    
  • Refactoring involves tearing apart classes into special-and general-purpose components, moving operations up or down the class hierarchy, and rationalizing the interfaces of classes. This consolidation phase produces many new kinds of objects, often by decomposing existing objects and using object composition instead of inheritance. Hence black-box reuse replaces white-box reuse. The continual need to satisfy more requirements along with the need for more reuse propels object-oriented software through repeated phases of expansion and consolidation – expansion as new requirements are satisfied, and consolidation as the software becomes more general.
  • This cycle is unavoidable. But good designers are aware of the changes that can prompt refactorings. Good designers also know class and object structures that can help avoid refactorings – their designs are robust in the face of requirement changes. A thorough requirements analysis will highlight those requirements that are likely to change during the life of the software, and a good design will be robust to them.
  • Our design patterns capture many of the structures that result from refactoring. Using these patterns early in the life of a design prevents later refactorings. But even if you don't see how to apply a pattern until after you've built your system, the pattern can still show you how to change it. Design patterns thus provide targets for your refactorings.

UML notations

• Class diagram notations
  • Abstract and concrete classes
  
  • Participant vs implied Client class
    
  • Class relationships
  
  
  • Pseudocode annotation
    
• Object Diagram
  
• Interaction Diagram