CS616 – Software
Engineering II
|
Lecture 8
|
1. Support for 3rd party external services
2. Complex pricing rules
3. Pluggable business rules
4. Design to refresh a GUI window when dale total
changes
·
Use-Case model - none
·
Use-Case model : SSDs
- since NEXGEN communicates with
external systems must update collaborations
·
Domain model – skip –
move to design
·
Use-Case model : System
Operation Contracts - none
1. Polymorphism (Pattern)
When related alternatives or behaviors vary by type (class), assign responsibilities for the behavior using polymorphic operations
How
to handle alternatives based on type? How to create pluggable components?
NEXGEN
– multiple 3rd party tax calculators
Figure– Polymorhism in adapting to different external tax calculators
NOTE: UML Notation for specifying interfaces ( a descriptor of operations without implementation), interface implementation, and “collection” return types.
Figure – UML notation for interfaces and return types
NOTE: A UML stereotype( a mechanism to categorize an element in some way) is used to indicate an interface
Assign a highly cohesive set
of responsibilies to an artificial or convenience class that does not represent
a problem domain concept - something
made-up, to support high cohesion, low coupling, and reuse
What object should have the
responsibility, when you do not want to violate high cohesion and low coupling,
but solutions offered by Expert are not appropriate?
·
Want to save Sale instances
in a relational database.
·
Information Expert justifies
assignement to Sale class itself
·
But:
o
Task requires large
number of supporting database-oriented operations – none related to saleness
o
Sale class must be
coupled to the relational database interface – increase coupling
o
Saving objects to a
relational database is a very general task
·
Solution – create a new
class that is solely responsible for saving objects into a persistent storage
medium
·
Assign the responsibilities
to an intermediate object to mediate between other components or services so
that they are not directly couples.
·
intermediary creates an
indirection between other components
·
Where to assign a
responsibility to avoid direct coupling between two (or more) things?
·
How to de-couple
objects so low coupling is supported and reuse potential remains high.
·
TaxCalculatorAdapter –
acts as intermediaries to external tax calculators
Figure - Indirection via the adapter.
·
Identify points of
predicted variations or instability
·
Assign responsibilities
to create a stable interface around them
How to design objects,
subsystems, and systems so that the variations or instability in these elements
does not have an undesirable impact on other elements.
·
Previous tax calculator
problem
·
Adding a level of
indirection protects within the system from variations in external APIs.
How to resolve incompatible
interfaces or provide a stable interface to similar components with different
interfaces
Solution
Convert the original
interface of a component into another interface through an intermediate adaptor
object.
·
Fundamental design
Principle: Design to maintain a separation of concerns
·
Factory (or Concrete
Factory) Pattern – pure fabrication “factory” object defined to create objects
·
Advantages:
o
Separate the
responsibility of complex object creation into cohesive helper objects
o
Hide complex creation
logic
o
Allow introduction of
performance-enhancing memory management strategies
Figure – Factory Pattern
NOTE: inclusion of detailed pseufocode
Who should be responsible for
creating objects when there are special considerations
Solution
Create a Pure Fabrication
object called a factory that handles the creation
·
Who creates the factory
itself and how is it accessed?
·
Sometimes global
visibility is needed through a single access point – Singleton
Exactly one instance of a
class is allowed – it is a “singleton.” Objects need a global, single point of
access
Define a static method of
the class that returns the singleton.
Figure - Singleton pattern in the ServicesFactory class
·
How to design for
varying but related algorithms or policies?
·
How to design for the
ability to change these algorithms and policies?
Define each
algorithm/policy/strategy in a separate class, with a common interface
Figure – Pricing Strategy class
NOTE: Each getTotal method takes Sale as a parameter
How to treat a group or
composition structure of objects the same way (polymorphically) as a
non-composite (atomic) object?
Define classes for composite
and atomic objects so that they implement the same interface
Figure – Composite Pattern
·
A common, unified
interface to a disparate set of implementations or interfaces – such as within
a subsystem – is required.
·
There may be
undesirable coupling to many things in the subsystem, or the implementation of
the subsystem may change
·
Define a single point
of contact to the subsystem – a façade object that wraps the subsystem
·
The façade object
presents a single unified interface and is responsible for collaborating with the
subsystem components
·
Different kinds of
subscriber objects are interested in the state changes or events of a publisher
object, and want to react in their own unique way when the publisher generates
an event
·
Publisher wants to
maintain low coupling to the subscribers
·
Define a “subscriber”
or “linstener” interface.
·
Subscribers implement
this interface
·
Publisher can
dynamically register subscribers who are interested in an event and notify them
when the event occurs