Design Through Reuse

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 8
2. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, "Design Patterns - Elements of Reusable Object-Oriented Software", Addison Wesley, 1995.

Concepts of Reuse

• In academia it is important for each student to do their own work, without copying the work of others. This is becuase the true value of doing homework lies in the learning experience, not in the end product.
• In the real world, however, the goal is to produce solutions as quickly and efficiently as possible, and if reusing previously developed code, designs, or design concepts can aid int that endeavor, all the better.
• Reuse is often the first step towards developing detailed object designs.
• In this section we make the distinction between domain objects which exist in the client's domain ( book, meeting, deadline ), with solution objects, which only exist as part of the implemented solution ( communication link, password. )

Reuse Through Inheritance

• Delegation as opposed to Inheritance:

Reuse Through Frameworks

Adapting Commercial Off-The-Shelf ( COTS ) Software

Issues with Reuse

• Extra work required to develop adapters
• Little if any control over thiird-party software
• Resistance: Not Invented Here Syndrome

Design Patterns

( Handout )

• A Design Pattern is basically a well-documented, named, solution to a commonly encountered problem.
• A shared familiarity with design patterns among SW engineers working on a project makes it much easier to discuss and compare possible solutions.
• Design patterms were originally cataloged by a group of four object-oriented developers, ( Gamma et. al., a.k.a. "The gang of four" ), in their classic book:

• Gamma et. al. categorized their collection of design patterns into three broad categories:
  • Creational design patterns have the overall task of creating new objects in some specialized way.
  • Structural design patterns provide a supporting infrastructure.
  • Behavioral design patterns capture the interactive behavior of classes and objects working together.
  • They also classify patterns as being either object-oriented or class-oriented, though that distinction is less valuable.
• For each design pattern in the catalog, the following information is provided:

• The complete list of design patterns, broken down by category, with one-sentence descriptions is as follows:

• Many design patterns are related, or are commonly used together. The following diagram shows some of those relationships:

Creational Patterns

Singleton

• The basic idea behind singleton is to make the constructor private, and to provide a static getter that will get the one and only one instance upon demand, creating it if necessary:

Prototype

• The basic idea behind prototype is to define a clone( ) method in a parent class whose responsibility is to return a copy of itself, and then to override the method in subclasses. Then the client can make a copy of any object of any descendent type of the original parent class, without knowing or specifying what type of object is being created.
• The big challenge is writing the clone( ) method properly for each class, implementing either shallow or deep copying as appropriate.

Factory Method

• a.k.a. Virtual Constructor
• Defines a method in a parent class to create a new item, but then overrides the creation method in descendent classes to create specific types of items. At runtime polymorphism binds a function call to a specific subclass, thereby returning a specific type of item.
• In the example below, the FactoryMethod( ) function in the Creator class is defined to return a pointer to an object of type Product, but the ConcreteCreator class overrides the method to return a pointer to the more specific type ConcreteProduct:

Abstract Factory

• a.k.a. Kit
• Very similiar to the FactoryMethod pattern, in that it defines a creation method in a parent class and then uses polymorphism to override the creation method dynamically in descendent classes.
• The big difference is taht instead of defining just a single creation method, Abstract Factory defines multiple creation methods, in order to create groups of items that work well together.
• In the example below, the client uses an AbstractFactory to create a Product A and a Product B. Whether those products are ( an A1 and a B1 ) or ( an A2 and a B2 ) depends on exactly what specific type of AbstractFactory was used to produce them:

Builder

• Similar to Abstract Factory, the Builder pattern includes a number of creation methods that create products designed to fit together.
• The difference being that the Abstract Factory delivers each product as it is made, while the Builder adds each new product onto a growing complex object, which is not delivered until it is completed ( via a separate method. )
• The order in which the Builder methods are called, and the number of times each method is called ( if at all ) may or may not make a difference.
• In the diagram below the "BuildPart( )" method in the Builder class really should be a sequence of methods "BuildStep1( )", "BuildStep2( )", . . . "BuildStepN( ):

Structural Patterns

Adapter

• a.k.a. Wrapper
• The Adapter pattern is used when both the client that needs a service and the class that is prepared to deliver the service are already written, but have incompatible interfaces.
• Depending on the situation, the Adapter may be called upon to reformat information, convert data types, or even provide missing data, either by calculation, or by default, or by other means.
• Interestingly the Adapter pattern can be implemented either using multiple inheritance ( class adapter ), or inheritence and delegation ( object adapter ), and there are situations where it is preferable to choose one implementaiton over the other:

• In the following example the compare( ) method is defined to return an integer value of -1, 0, or 1, depending on whether a first object is less than, equal to, or greater than a second object.

Bridge

• a.k.a. Handle or Body
• The Bridge pattern is used to separate the interface to a service from its implementation, allowing either one to be extended independently of the other.
• The Bridge pattern offers more flexibility and more independence between the two ends of the connection than other alternatives.
• Generally the Bridge is used as an original design, when both the interface and its implementation are being developed as new classes, in contrast to the Adapter pattern which is generally used to connect two previously existing classes.
• In the diagram below, "Abstraction" could be better named "Interface":

• In the following example, league data for the ARENA applicaiton can either be stored in XML format ( a flat file, suitable for small leagues ), or JDBC ( a database suitable for larger leagues ), and can dynamically switch from one to the other at the request of the league owner. ( The stub is provided for development work only. )

Decorator

Facade

Proxy

• a.k.a. Surrogate
• Basically a Proxy acts as a "local" stand-in for or representattion of a "remote" object, with the ability to access the "remote" object as needed. The exact meaning of "local" and "remote" vary with the situation and type of Proxy.
• Four common types of Proxy are:

1. A remote proxy provides a stand-in for an object that is in a different address space, e.g. on a separate computer or on the hard drive instead of in RAM.
2. A virtual proxy creates expensive objects on demand. For example a document may use proxies to save time by not loading in images that do not appear on the screen ( at the moment. )
3. A protection proxy controls access to the original object.
4. A smart reference provides more sophisticated indirect access than ordinary pointers, such as doing reference counting and garbage collection.

Composite

• Composite builds a hierarchical tree composed of group nodes ( having children ) and leaf nodes ( not having children )
• In general there may be multiple different kinds of group nodes and/or multiple different kinds of leaves. Group nodes may or may not be allowed to have zero children, and/or may have other restrictions depnding on the particular application.

Flyweight

• The Flyweight pattern is used when a large number of copies are needed of relatively few original objects, and when the only real difference between the copies is state information that can be factored out.
• In the last diagram shown under Composite above, only one real copy of the geometery of the car wheel needs to be loaded, with position and rotation information for each wheel stored elsewhere in the scene graph tree.
• In the example below there may logically be hundreds of thousands of characters in a document, but physically they can all refer to a common pool of approximately 52 character objects:

Behavioral Patterns

Observer

• a.k.a. Depndents, Publish-Subscribe
• The basic idea behind Observer is that one object "registers" with another that they are interested in any changes that might take place, and are then "notified" when such changes do indeed occur.
• Depending on the implementation, the notification could include details of the change, or just notification that a change has taken place.
• The Model-View-Controller architecture typically uses the Observer pattern.

Command

• a.k.a. Action, Transaction
• The Command design pattern encapsulates a single action.
• Useful for:
  • logging actions
  • undoing actions, including a string of multiple actions.
  • repeating actions, e.g. re-do or macros.
  • replaying actions, e.g. for playback.
  • implementing menus, control keys, etc.
• Note how the macro example below also makes use of Composite.

Mediator

Chain of Responsibility

State

Memento

Interpreter

Iterator

Visitor

Strategy

• a.k.a. Policy
• The Strategy design pattern encapsulates the overall steps of an algorithm, allowing the client to delegate to different algorithms for performing the same task depending on the current situation.

Template Method

• Similar to the Strategy pattern, the Template Method pattern encapsulates an algorithm and provides for run-time variations in the algorithm.
• Instead of changing hte entire algorithm via delegation the way that Strategy does, Template Method preserves the overall algorithm but allows the implementation of individual steps to be modified via overriding in child classes.