CS616 – Software Engineering II
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
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
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
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
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