View
214
Download
0
Embed Size (px)
Citation preview
Oct 2002 91.3913 R McFadyen 1
Recall UML Class Diagram
BusRoute BusStopList
BusStopBusList
Bus PersonList
Person
passengers
buses
busStops
waiting
0..*
0..*
0..*
Oct 2002 91.3913 R McFadyen 2
BusRoute BusStopList
BusStopBusList
Bus PersonList
Person
passengers
buses
busStops
waiting
0..*
0..*
0..*
Find all persons waiting at any bus stop on a bus route
Collaborating classes:
Oct 2002 91.3913 R McFadyen 3
class BusRoute { BusStopList busstops; void printWaitingPassengers () {
busstops->printWaitingPassengers (); }}class BusStopList { BusStop stops[]; void printWaitingPassengers () {
for (int i = 0; i < stops.length; i++) stops[i].printWaitingPassengers ();
} }
Applying Law of Demeter - Partial Java Solution
Oct 2002 91.3913 R McFadyen 4
class BusStop { PersonList waiting; void printWaitingPassengers () {
waiting.print (); }}class PersonList { Person people[]; void print () { for (int i = 0; i < people.length; i++) people[i].print (); }}class Person { String name; void print () { System.stdout.println (name); } }
Applying Law of Demeter - Partial Java Solution
Oct 2002 91.3913 R McFadyen 5
Law of Demeter
What changes are needed to the current solution in order to adapt to the changes in the model (see next), and still follow the LoD?
Oct 2002 91.3913 R McFadyen 6
BusRoute BusStopList
BusStopBusList
Bus PersonList
Person
passengers
busesbusStops
waiting
0..*
0..*
0..*
Suppose the class model is modified to incorporate Villages:
VillageList
Village
villages
0..*
Oct 2002 91.3913 R McFadyen 7
Façade
&
Observer (Publish-subscribe)
Oct 2002 91.3913 R McFadyen 8
Facade P. 368+
Main Entry: fa·cade Variant(s): also fa·çade /f&-'säd/Function: nounEtymology: French façade, from Italian facciata, from faccia face, from (assumed) Vulgar Latin faciaDate: circa 16811 : the front of a building; also : any face of a building given special architectural treatment <a museum's east facade>2 : a false, superficial, or artificial appearance or effect
From www.m-w.com
Oct 2002 91.3913 R McFadyen 9
Facade P. 368+
Problem: There are a set of classes, a subsystem, that you need to interact with for some purpose, but you don’t want to create dependencies on this subsystem.
Solution: Create a class that wraps this subsystem. The wrapper will define an interface that hides the details (classes, methods) of the subsystem.
The façade is a “front-end” object that defines a single point of entry to the subsystem’s services.
Showing the classes as a package (a subsytem)
A façade,
a wrapper
Oct 2002 91.3913 R McFadyen 10
Facade P. 368+
Text example.
NextGen POS is a system to be sold to many customers.
Customers will want to customize NextGen POS
Example: Payment rules may vary for gift certificates. How are gift certificates to be handled:
•One per customer per purchase?
•No change is returned - another gift certificate issued?
To allow flexibility, it is desired to reduce the impact of changes to the rest of the system
To reduce the impact, the Façade pattern is applied
The subsytem will be hidden behind a single object
Oct 2002 91.3913 R McFadyen 11
Sale objects, in the Domain package, access the POS Rule Engine via the façade in the POSRuleEngine package
if ( POSRuleEngineFacade.getInstance().isInvalid(…) ...
On page 370:Public class Sale …
ASIDE:
on Page 371 - mention of the Singleton pattern
Figure 23.19
Oct 2002 91.3913 R McFadyen 12
if ( POSRuleEngineFacade.getInstance().isInvalid(…) ...
On page 370:Public class Sale …
ASIDE:
on Page 371 - mention of the Singleton pattern
Singleton is a pattern whereby one instance of an object of some class is created/allowed. The class will have a static method that returns the singleton.
Façades are normally accessed via the Singleton pattern.
Oct 2002 91.3913 R McFadyen 13
Facade
:Sale :POSRuleEngineFacade
isInvalid (…)
[valid] add (…)
:
makeLineItem()
:SalesLineItem
.
.
.
Oct 2002 91.3913 R McFadyen 14
Example: (from Design Patterns Explained by Shalloway & Trott)
Suppose a client object must deal with Databases, Models, and Elements. The client must first open the Database, then get a Model, then queries the Model for Elements, and finally gets Elements.
I.e.
Client
Database
Model
Element
Oct 2002 91.3913 R McFadyen 15
Example: (from Design Patterns Explained by Shalloway & Trott)
It may be easier to create a Database Façade that can be used by clients
I.e.
ClientA
Database
Model
Element
Db FacadeClientB
ClientC
To use the database, one only needs to become aware of DbFacade, and learn how to use it.
Oct 2002 91.3913 R McFadyen 16
When to use Facade
(from Design Patterns Explained by Shalloway & Trott)
•To create a simpler interface: number of methods, number of objects one has to deal with
•The system being hidden may have an older, more complex interface
•The cost of developing the façade, and of developers learning the new interface may be less than learning the old one
•You may only be needing a subset of the functionality
•You may want to augment the functionality of the system
•To facilitate tracking system usage – by forcing all requests to go through a Façade class, one can easily track the usage.
•To facilitate subsystem replacement – only one class is affected, the Façade class. This is the motivation in Larman’s example.
Oct 2002 91.3913 R McFadyen 17
Observer P. 368+
Also known as Publish-Subscribe
Applied in order to implement the Model-View Separation principle (see pages 471+)
•model and view are separated
•non-GUI objects are not directly coupled to GUI components
•domain objects are not directly coupled to window objects
•same as Model-View-Controller (MVC) principle that came from Smalltalk
Oct 2002 91.3913 R McFadyen 18
Observer
Problem: There are many objects (subscribers) needing to know of the state changes, or events, of another object (publisher), and we want to keep the coupling low.
Solution: Define a subscriber or listener interface that is implemented by the subscribers.
Situations:
Text example: A user interface object, a window, needs to be informed when a domain object changes
In some distributed meta-data environments, replicas need to be notified when the source changes
Alarm systems need notification of alarms being triggered
...
Oct 2002 91.3913 R McFadyen 19
Figure 23.20 the display must reflect the correct total
There is a requirement for a window to be updated whenever the total value of the sale changes
Oct 2002 91.3913 R McFadyen 20
Observer
Text example.
There is a requirement for a window to be updated whenever the total of the sale changes
A subscriber interface, PropertyListener, is defined.
SaleFrame1 is defined to inherit the PropertyListener interface. This will allow SaleFrame1 to be alerted of changes in the value of the sale total
A reference to the Sale is passed to SaleFrame1 when SaleFrame1 is initialized. This allows SaleFrame1 to subscribe to the Sale instance
The Sale only knows of objects that subscribe to it; it does not know what class of object they are - so, coupling is kept low.
Oct 2002 91.3913 R McFadyen 21
Figure 23.21 The Observer Pattern in a DCD
Oct 2002 91.3913 R McFadyen 22
Figure 23.22 a window subscribing
When a SaleFrame1 (the subscriber) is initialized, it subscribes to the Sale (the publisher)
Oct 2002 91.3913 R McFadyen 23
Figure 23.23 a sale publishing a change
A Sale receives a message changing its state. The Sale invokes its method, publishPropertyEvent, which will in turn notify any subscribers of the change
Note the activations for the sale
Oct 2002 91.3913 R McFadyen 24
Figure 23.24 a window receiving notification
The window receives notification of the state change and modifies its display appropriately
Notice that this is a continuation from the previous sequence diagram