Ooad Session 11

8/11/2019 Ooad Session 11

1/60


2/60


3/60


4/60


5/60


6/60


7/60


8/60


9/60


10/60


11/60


12/60


13/60


14/60


15/60


16/60


17/60


18/60


19/60


20/60


21/60


22/60


23/60


24/60


25/60


26/60


27/60


28/60


29/60


30/60


31/60


32/60


33/60


34/60


35/60

U d t di it (GOF) ith l


36/60

Understanding composite (GOF) with an example

Suppose a store has the followingpolicies in effect for a particular day:20% senior discount policy.

Preferred customer discount of 15% off sales over $400.On day,there is $50 off purchases over

$500.Buy 1 case of Darjeeling tea, get 15%

discount off of everything.July 30, 2014 36BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy

P bl


37/60

ProblemSuppose a senior who is also

a preferred customer buys 1case of Darjeeling tea, and$600 of veggieburgers.

What pricing policy should beapplied?

July 30, 2014 37BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy


38/60

Solution using conflict resolution strategy

In this strategy a store applies thefollowing:Best for the customer (lowest

price)Highest pricing strategy (during a

difficult financial period)


M ltiple Co E isting Str tegies


39/60

Multiple Co-Existing Strategies

One sale may have severalpricing strategies

Pricing strategy can be relatedto the type of customer

Pricing strategy can be relatedto the type of product beingbrought



40/60

Multiple co-existing strategies(2)The Product Specification must be known by

the StrategyFactory at the time of creationof a pricing strategy influenced by theproduct.

Is there a way to change the design so thatthe Sale object does not know if it is dealingwith one or many pricing strategies, and

offer a design for the conflict resolution? And the answer is yes, with the composite

pattern.July 30, 2014 40BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy

Collaboration with a Composite


41/60

Collaboration with a Composite

In this the Sale does notknow or care if its pricingstrategy is an atomic objector a composite strategy thatis it looks the same to theSale object.


Creating Multiple Sale Pricing Strategies


42/60

Creating Multiple Sale Pricing Strategies

There are three points in the scenario

where pricing strategies may beadded to the composite:Current store-defined discount,added

when the sale is created.Customer type discount,added when the

customer type is communicated to the

POS.Product type discount added when the

product is entered to the sale.July 30, 2014 42BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy


43/60

Creating a Composite Strategy for the First Case.


Creating a Process sale for the Second Case


44/60

Creating a Process sale for the Second CaseUse case UCI: Process Sale

Extensions (or Alternative Flows)Customer says they are eligible for a discount (e.gemployee, preferred customer)

Cashier signals discount request.

Cashier enters Customer identification System presents discount total, based ondiscount rules.



45/60

Creating a Pricing Strategy for a CustomerDiscount


Note


46/60

Note Although this application of composite

was to a strategy family, theComposite pattern can be applied toother kinds of objects

For example, it is common to create"macro commands " - commands

that contain other commands -through the use of Composite.


Note(2)


47/60

Note(2)

Composite is often used with theStrategy and Command Patterns.

Composite is based on

Polymorphism and providesProtected Variations to a client so

that it is not impacted if its relatedobjects are atomic or composite.


Facade(GOF)


48/60

Facade(GOF)

Context/Problem A common, unified interface to a

disparate set of implementations or interfaces- such as within a subsystem-is required. There may be undesirablecoupling to many things in thesubsystem, or the implementation of the subsystem may change.What to do?


Faade(GOF) (2)


49/60

Faade(GOF) (2)

SolutionDefine a single point of contact to

the subsystem- a facade object that

wraps the subsystem. This facadeobject presents a single unifiedinterface and is responsible for collaboration with the subsystemcomponents.


Facade


50/60

Facade A Facade is a front-end object that is the

single point of entry for the services of a subsystem; the implementation andother components of the subsystemare private and can't be seen byexternal components.

Facade provides Protected Variationsfrom changes in the implementation of a subsystem.


Example for a Facade


51/60

Example for a FacadeDefine a rule engine subsystem, whose

specific implementation is not yet known.Itwill be responsible for evaluating a set of rules against an operation, and thenindicating if any of the rules invalidated theoperation.

The facade object to this subsystem will becalled POSRuleEngineFacade.

The designer decides to place calls to thisfacade near the start of the methods thathave been defined as the points for pluggable rules.


Explanation


52/60

ExplanationWith this design, the complexity and

implementation of how rules will bepresented and evaluated are hidden in therules engine subsystem. Accessed throughthe POSRuleEngineFacade facade.

The subsystem hidden by the facade objectcould contain dozens or hundreds of classes of objects, or even a non-object-

oriented solution, yet as a client to thesubsystem one can see only its one publicaccess point.


Summary of Facade Objects


53/60

Summary of Facade Objects

Facades are often accessedthrough singleton.

The facade pattern is simple,and widely used.

It hides a subsystem behindan object.July 30, 2014 53BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy

UML Package Notation


54/60

UML Package Notation


Observer/Publish-Subscribe/ Delegation Event


55/60

gModel

Context/ProblemDifferent kinds of subscriber objects are

interested in the state changes or

events of a publisher object, and wantto react in their own unique way whenthe publisher generates an event.

Moreover, the publisher wants tomaintain low coupling to thesubscribers.


Solution


56/60

Solution

Define a subscriber or Listener interface.

Subscribers implement this

interface.The publisher can dynamically

register subscribers who areinterested in an event, and notifywhen an event occurs.


The Observer Pattern


57/60

The Observer PatternObserver Is not only for connecting

UIs and Model Objects but alsoused for GUI widget event

handling in both Java technologyand Microsoft's .Net.One publisher can have many

subscribers for an event.



58/60

Conclusion


59/60

ConclusionObjects can be designed and

responsibilities assigned withthe support of patterns.

They provide an explainable setof idioms by which welldesigned object-orientedsystems can be built.



60/60

THANK YOU

Documents

Ooad Session 11