oomd 9th asg take nly print of dis

[minal patil]

ASSIGNMENT NO. 9
TITLE:- STUDY OF DESIGN PATTERNS

OBJECTIVES:-
To study Design Patterns.
To study how to draw UML diagrams using design pattern.

Theory :-
In software engineering, a design pattern is a general reusable
solution to a commonly occurring problem within a given context
in software design. A design pattern is not a finished design that can
be transformed directly into code. It is a description or template for
how to solve a problem that can be used in many different situations.


Name
Description
Abstract factory
Provide an interface for creating families of related or dependent
objects without specifying their concrete classes.
Singleton
Ensure a class has only one instance, and provide a global point of
access to it.
Builder
Separate the construction of a complex object from its representation
allowing the same construction process to create various
representations.
Prototype
Specify the kinds of objects to create using a prototypical instance,
and create new objects by copying this prototype.
Decorator
Attach additional responsibilities to an object dynamically keeping
the same interface. Decorators provide a flexible alternative to
subclassing for extending functionality.
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.
Proxy
Provide a surrogate or placeholder for another object to control
access to it.
Iterator
Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.
Memento
Without violating encapsulation, capture and externalize an object's
internal state allowing the object to be restored to this state later.
Observer
Define a one-to-many dependency between objects where a state change
in one object results in all its dependents being notified and updated
automatically.




Singleton Design
Pattern

Intent

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

Motivation

It's important for some classes to have exactly one instance. Although
there can be many printers in a system, there should be only one
printer spooler. There should be only one file system and one window
manager. A digital filter will have one A/D converter. An accounting
system will be dedicated to serving one company.

Applicability

Use the Singleton pattern when
l . There must be exactly one instance of a class, and it must be
accessible to clients from a well known access point.
When the sole instance should be extensible by sub classing and
clients should be able to use an extended instance without modifying
their code.

Structure




Collaborations
l. Clients access a Singleton instance solely through Singleton's
Instance operation.

Consequences

The Singleton pattern has several benefits:
1. Controlled access to sole instance.
2. Reduced name space.
3. Permits refinement of operations and representation.
4. Permits a variable number of instances.
5. More flexible than class operations.



Abstract Factory

Intent

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

Applicability

Use the Abstract Factory pattern when
l. A system should be independent of how its products are created,
composed, and represented.
2. A system should be configured with one of multiple families of
products.
3. A family of related product objects is designed to be used
together, and you need to enforce this constraint.
4. You want to provide a class library of products, and you want to
reveal just their interfaces, not their implementations.

Structure


Collaborations

1. Normally a single instance of a ConcreteFactory class is created at
run-time.
2. AbstractFactory defers creation of product objects to its
ConcreteFactory subclass.

Consequences

The Abstract Factory pattern has the following benefits and
liabilities:
1. It isolates concrete classes.
2. It makes exchanging product families easy
3. It promotes consistency among products.
4. Supporting new kinds of products is difficult.


Prototype pattren :

Intent

specifying the kind of objects to create using a prototypical instance
creating new objects by copying this prototype

Motivation

The Prototype design pattern is the one in question. It allows an
object to create customized objects without knowing their class or any
details of how to create them. Up to this point it sounds a lot like
the Factory Method pattern, the difference being the fact that for the
Factory the palette of prototypical objects never contains more than
one object.

Implementation

The pattern uses abstract classes, as we will see below and only three
types of classes making its implementation rather easy.

The classes participating to the Prototype Pattern are:
Client - creates a new object by asking a prototype to clone itself.
Prototype - declares an interface for cloning itself.
Concrete Prototype - implements the operation for cloning itself.


Applicability & Examples

Use Prototype Pattern when a system should be independent of how its
products are created, composed, and represented, and:
Classes to be instantiated are specified at run-time
Avoiding the creation of a factory hierarchy is needed
It is more convenient to copy an existing instance than to create a
new one.






Decorator pattern :

Intent
The intent of this pattern is to add additional responsibilities
dynamically to an object.

Motivation
Extending an objects functionality can be done statically (at compile
time) by using inheritance however it might be necessary to extend an
objects functionality dynamically (at runtime) as an object is used.

Implementation
The figure below shows a UML class diagram for the Decorator Pattern:
Applicability & Examples
Example - Extending capabilities of a Graphical Window at runtime


Consequences
Decoration is more convenient for adding functionalities to objects
instead of entire classes at runtime. With decoration it is also
possible to remove the added functionalities dynamically.
Decoration adds functionality to objects at runtime which would make
debugging system functionality harder.
5. Iterator pattren :
Intent:

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

Motivation :

We define an AbstractList class that provides a common interface for
manipulating lists. Similarly, we need an abstract Iterator class that
defines a common iteration interface. Then we can define concrete
Iterator subclasses for the different list implementations. As a
result, the iteration mechanism becomes independent of concrete
aggregate classes.

Applicability

Use the Iterator pattern
to access an aggregate object's contents without exposing its internal
representation.
to support multiple traversals of aggregate objects.
to provide a uniform interface for traversing different aggregate
structures (that is, to support polymorphic iteration).
Structure


Participants

Iterator : defines an interface for accessing and traversing elements.
ConcreteIterator : implements the Iterator interface. keeps track of
the current position in the traversal of the aggregate.
Aggregate : defines an interface for creating an Iterator object.
ConcreteAggregate : implements the Iterator creation interface to
return an instance of the proper ConcreteIterator.
Consequences
1. It supports variations in the traversal of an aggregate
2. Iterators simplify the Aggregate interface.
3. More than one traversal can be pending on an aggregate.
Observer pattern :

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

Applicability
Use the Observer pattern in any of the following situations:
When an abstraction has two aspects, one dependent on the other.
Encapsulating these aspects in separate objects lets you vary and
reuse them independently.
When a change to one object requires changing others, and you don't
know how many objects need to be changed.
When an object should be able to notify other objects without making
assumptions about who these objects are. In other words, you don't
want these objects tightly coupled.

Structure

Participants
Subject : knows its observers. Any number of Observer objects may
observe a subject.
provides an interface for attaching and detaching Observer objects.
Observer : defines an updating interface for objects that should be
notified of changes in a subject.
ConcreteSubject : stores state of interest to ConcreteObserver
objects. sends a notification to its observers when its state changes.
ConcreteObserver : maintains a reference to a ConcreteSubject
object. stores state that should stay consistent with the subject's.
implements the Observer updating interface to keep its state
consistent with the subject's.

Collaborations
ConcreteSubject notifies its observers whenever a change occurs that
could make its observers' state
inconsistent with its own. After being informed of a change in the
concrete subject, a ConcreteObserver object may query the subject .
for information. ConcreteObserver uses this information to reconcile
its state with that of the subject.The following interaction diagram
illustrates the collaborations between a subject and two observers:

Consequences
The Observer pattern lets you vary subjects and observers
independently. You can reuse subjects without reusing their observers,
and vice versa. It lets you add observers without modifying the
subject or other observers.
1. Abstract coupling between Subject and Observer.
2. Support for broadcast communication.
3. Unexpected updates

The following diagram depicts a simple ChangeManager-based
implementation of the Observer pattern.SimpleChangeManager is naive in
that it always updates all observers of each subject. In contrast,
DAGChangeManager handles directed-acyclic graphs of dependencies
between subjects and their observers. A DAGChangeManager is preferable
to a SimpleChangeManager when an observer observes more than one
subject. In that case, a change in two or more subjects might cause
redundant updates. The AGChangeManager ensures the observer receives
just one update. SimpleChangeManager is fine when multiple updates
aren't an issue of updates to observers and their dependent objects.
Moreover, dependency criteria that aren't well-defined or maintained
usually lead to spurious updates, which can be hard to track down.This
problem is aggravated by the fact that the simple update protocol
provides no details on what changed in the subject.


Memento pattren :

Intent

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

Applicability

Use the Memento pattern when a snapshot of (some portion of) an
object's state must be saved so that it can be restored to that state
later, and a direct interface to obtaining the state would expose
implementation details and break the object's encapsulation.


Structure





Consequences

The Memento pattern has several consequences:
1. Preserving encapsulation boundaries
2. It simplifies Originator
3. Using mementos might be expensive.
4. Defining narrow and wide interfaces. It may be difficult in some






Builder pattern :
Intent
Separate the construction of a complex object from its representation
so that the same construction process can create different
representations.
Applicability
Use the Builder pattern when
l .The algorithm for creating a complex object should be independent
of the parts that make up the object and how they're assembled.
2 . The construction process must allow different representations for
the object that's constructed.
Structure

Collaborations
l The client creates the Director object and configures it with
the desired Builder object.
2 Director notifies the builder whenever a part of the product
should be built.
3 Builder handles requests from the director and adds parts to the
product.
4 The client retrieves the product from the builder.
The following interaction diagram illustrates how Builder and Director
cooperate with a client.

Consequences
Here are key consequences of the Builder pattern:
1. It lets you vary a product's internal representation.
2. It isolates code for construction and representation.
9. Proxy desing pattern :

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

Motivation
One reason for controlling access to an object is to defer the full
cost of its creation and initialization until we actually need to use
it. Consider a document editor that can embed graphical objects in a
document. Some graphical objects, like large raster images, can be
expensive to create. But opening a document should be fast, so we
should avoid creating all the expensive objects at once when the
document is opened.
The following class diagram illustrates this example in more detail.

The document editor accesses embedded images through the interface
defined by the abstract Graphic class. ImageProxy is a class for
images that are created on demand. ImageProxy maintains the file name
as a reference to the image on disk. The file name is passed as an
argument to the ImageProxy constructor. ImageProxy also stores the
bounding box of the image and a reference to the real Image instance.
This reference won't be valid until the proxy instantiates the real
image. The Draw operation makes sure the image is instantiated before
forwarding it the request. GetExtent forwards the request to the image
only if it's instantiated; otherwise ImageProxy returns the extent it
stores.

Applicability
Proxy is applicable whenever there is a need for a more versatile or
sophisticated reference to an object than
a simple pointer. Here are several common situations in which the
Proxy pattern is applicable:
1. A remote proxy provides a local representative for an object in a
different address space.
2. A virtual proxy creates expensive objects on demand. The ImageProxy
described in the Motivation is an example of such a proxy.
3. A protection proxy controls access to the original object.
4. A smart reference is a replacement for a bare pointer that performs
additional actions when an object is accessed.

Structure



Implementation

The Proxy pattern can exploit the following language features:

Overloading the member access operator in C++. C++ supports
overloading operator->, the member access operator. Overloading this
operator lets you perform additional work whenever an object is
dereferenced.

Using doesNotUnderstand in Smalltalk. Smalltalk provides a hook that
you can use to
support automatic forwarding of requests. Smalltalk calls
doesNotUnderstand: aMessage
when a client sends a message to a receiver that has no
corresponding method. The Proxy
class can redefine doesNotUnderstand so that the message
is forwarded to its subject.

Proxy doesn't always have to know the type of real subject. If a Proxy
class can deal with its subject solely through an abstract interface,
then there's no need to make a Proxy class for each RealSubject class;
the proxy can deal with all RealSubject classes uniformly. But if
Proxies are going to instantiate RealSubjects (such as in a virtual
proxy), then they have to know the concrete class.






Facade design pattern :
Intent
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.

Motivation
Structuring a system into subsystems helps reduce complexity. A common
design goal is to minimize the
communication and dependencies between subsystems. One way to achieve
this goal is to introduce a facade object that provides a single,
simplified interface to the more general facilities of a subsystem.

Consider for example a programming environment that gives applications
access to its compiler subsystem. This subsystem contains classes such
as Scanner, Parser, ProgramNode, BytecodeStream, and
ProgramNodeBuilder that implement the compiler. Some specialized
applications might need to access these classes directly. But most
clients of a compiler generally don't care about details like parsing
and code generation; they merely want to compile some code. For them,
the powerful but low-level interfaces in the compiler subsystem only
complicate their task.
To provide a higher-level interface that can shield clients from these
classes, the compiler subsystem also includes a Compiler class. This
class defines a unified interface to the compiler's functionality. The
Compiler class acts as a facade: It offers clients a single, simple
interface to the compiler subsystem. It glues together the classes
that implement compiler functionality without hiding them completely.
The compiler facade makes life easier for most programmers without
hiding the lower-level functionality from the few that need it.

Applicability
Use the Facade pattern when
You want to provide a simple interface to a complex subsystem.
Subsystems often get more complex as they evolve. Most patterns, when
applied, result in more and smaller classes. This makes the subsystem
more reusable and easier to customize, but it also becomes harder to
use for clients that don't need to customize it. A facade can provide
a simple default view of the subsystem that is good enough for most
clients. Only clients needing more customizability will need to look
beyond the facade.

There are many dependencies between clients and the implementation
classes of an abstraction. Introduce a facade to decouple the
subsystem from clients and other subsystems, thereby promoting
subsystem independence and portability.


Structure


Implementation
Consider the following issues when implementing a facade:
1. Reducing client-subsystem coupling. The coupling between clients
and the subsystem can be reduced evenfurther by making Facade an
abstract class with concrete subclasses for different implementations
of a subsystem. Then clients can communicate with the subsystem
through the interface of the abstract Façade class. This abstract
coupling keeps clients from knowing which implementation of a
subsystem is used.

2. Public versus private subsystem classes. A subsystem is analogous
to a class in that both have interfaces, and both encapsulate something
—a class encapsulates state and operations, while a subsystem
encapsulates classes. And just as it's useful to think of the public
and private interface of a class, we can think of the public and
private interface of a subsystem. The public interface to a subsystem
consists of classes that all clients can access; the private interface
is just for subsystem extenders. The Facade class is part of the
public interface, of course, but it's not the only part. Other
subsystem classes are usually public as well.

Conclusion:- Thus we have studied Design Pattern.

[minal patil]