4.

2 DESIGN PATTERNS

- Design Patterns – creational - factory method - structural – Bridge – Adapter -

behavioral – Strategy – observer.

GOF design patterns: GOF : Gang of Four (Part B)

ü Elements of Reusable object oriented s/w book created by Erich gamma, Richard Helm,
Ralph Johnson and John vissides

ü The Authors are referred as the GOF

ü 23 patterns useful during object design patterns

ü 15 are common and most useful

----------------------------------------------------------

Name: Adapter

Problem:

How to resolve incompatible interfaces, (or) provide a stable interface to similar

Solution:

Convert the original interface of component into another interface, through an intermediate
adapter object.

Example: POS system

• Pos needs several kinds of external third party services, including Tax calculators,
Credit Authorization, inventory systems, and accounting systems

• Each has a different API which cant be changed

Solution is to add a level of indirection objects that adapt the varying external interfaces to a
consistent interface used with in the application
The adapter raises a new problem in the design:

ü Adapter pattern solution for external services with varying interfaces, who creates
adapter?

ü How to determine which class of adapter to create, such as Taxmaster Adapter(or)

ü Factory creates the factory object.

Name : Factory

Problem:

ü who should be responsible for creating objects for adapter?

Solution:

ü create object called factory that handles the creation.

ü This is also called simple factory (or) concrete factory.

• Service factory raises another new problem in the design. Who creates the factory?

How is it accessed?

Solution:

ü First only one instance of the factory is needed with in the process.

ü Second the methods of this factory may need to be called from various places in the code
for adapter for calling on the external services.

ü How to get visibility to this single services factory instance?

---------------------------------------------------------------------------------------

Name: singleton
Problem:

ü Exactly one instance of a class is allowed. It is a singleton.

ü Object need a global and single point of access.

Solution:

Define a static method of the class that returns the singleton.

---------------------------------------------------------------------------------------------------

Observer Pattern

• Context / Problem: Different kinds of subscriber objects are interested in the state
changes or events of a publisher object, and want to react in their own way when the
publisher generates the event. …

• Solution:

Define a “subscriber” or “listener” interface. Subscribers implement this interface. The

• Clarification: Publisher can dynamically process registration requests from subscribers.

• An interface is defined; in this case, PropertyListener with the operatin

• Define the window to implement the interface.

– SaleFrame1 will implement the method onPropertyEvent.

– When the SaleFrame1 window is initialized, pass it the Sale instance from
which it is displaying the total.

• Note that the Sale does not know about SaleFrame1 objects; rather, it only knows about
objects that implement the PropertyListener interface.

• This lowers the coupling of the Sale to the window – the coupling is only to an
interface, not to a GUI class.

_____________________________________________________________________

Designing for Visibility (part B)

In common usage, visibility is the ability of an object to "see" or have a reference to another
object. More generally, it is related to the issue of scope.

There are four common ways that visibility can be achieved from object A to object B:
Ø Attribute visibility— B is an attribute of A.
Ø Parameter visibility— B is a parameter of a method of A.
Ø Local visibility— B is a (non-parameter) local object in a method of A.
Ø Global visibility— B is in some way globally visible.

The motivation to consider visibility is this:

For an object A to send a message to an object B, B must be visible to A.

Attribute Visibility
 Attribute visibility from A to B exists when B is an attribute of A.

It is a relatively permanent visibility because it persists as long as A and B exist.

This is a very common form of visibility in object-oriented systems.

In a Java class definition for Register, a Register instance may have attribute visibility to a
ProductCatalog, since it is an attribute (Java instance variable) of the Register.

This visibility is required because in the enterItem diagram ,a Register needs to send the
getSpecification message to a ProductCatalog:

Parameter Visibility:

Parameter visibility from A to B exists when B is passed as a parameter to a method of A.

It is a relatively temporary visibility because it persists only within the scope of the
method.

After attribute visibility, it is the second most common form of visibility in object-oriented
systems.

Local Visibility

Local visibility from A to B exists when B is declared as a local object within a method of
A.

It is a relatively temporary visibility because it persists only within the scope of the
method.

After parameter visibility, it is the third most common form of visibility in object-oriented
systems.

Global Visibility

Global visibility from A to B exists when B is global to A.

It is a relatively permanent visibility because it persists as long as A and B exist.

One way to achieve global visibility is to assign an instance to a global variable, which is
possible in some languages, such as C++, but not others, such as Java.

The preferred method to achieve global visibility is to use the Singleton pattern.

Operation Contracts (part B)

• Use cases are the primary mechanism in the UP to describe system behavior, and are
usually sufficient.

• However, sometimes a more detailed description of system behavior has value.

• Contracts for operations can help define system behavior.

Contracts describe detailed system behavior in terms of state changes to objects in the Domain
Model, after a system operation has executed

Syntax for Operation Contract

Operation: Name Of operation, and parameters.

Cross References: (optional) Use cases this can occur within.

Preconditions: Noteworthy assumptions about the state of the system or objects in the
Domain Model before execution of the operation.

Post conditions: The state of objects in the Domain Model after completion of the operation.

Example Contract: enterItem

Contract CO2: enterItem

Operation: enterItem(itemID : ItemID, quantity : integer)

Cross References: Use Cases: Process Sale

Postconditions: -A SalesLineItem instance sli was

created (instance creation)

-sli was associated with the

current Sale (association formed)

-sli.quantity became quantity

(attribute modification)

-sli was associated with a

ProductSpecification, based on

itemID match (association formed)

How to express post condition?

• Express postconditions in the past tense, to emphasize they are declarations about a
state change in the past.

– (better) A SalesLineItem was created.

– (worse) Create a SalesLineItem.

Writing Contracts Leads to Domain Model Updates

• New conceptual classes, attributes, or associations in the Domain Model are often
discovered during contract writing.

• Enhance the Domain Model as you make new discoveries while thinking through the
operation contracts.

Contracts vs. Use Cases

• The use cases are the main repository of requirements for the project. They may provide
most or all of the detail necessary to know what to do in the design.
• If the details and complexity of required state changes are awkward to capture in use cases,
then write operation contracts.