程序代写代做代考 flex Java database algorithm gui concurrency chain interpreter Software Construction & Design 1
Software Construction & Design 1
The University of Sydney Page 1
Software Design and
Construction 2
SOFT3202 / COMP9202
Introduction
Software Testing
School of Information Technologies
Dr. Basem Suleiman
The University of Sydney Page 2
Copyright Warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been reproduced and communicated to
you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the
Act ).
The material in this communication may be subject
to copyright under the Act. Any further copying or
communication of this material by you may be the
subject of copyright protection under
the Act.
Do not remove this notice.
The University of Sydney Page 3
Agenda
– OO Principles
– Design Principles
– Overview of Design Patterns
– GoF Design Patterns (review)
The University of Sydney Page 4
OO Principles
Review
Slides from SOFT2201 by Bernhard Scholz
The University of Sydney Page 5
OO Principles
– Abstraction
– Encapsulation
– Polymorphism
– Inheritance
The University of Sydney Page 6
Abstract Classes
– Abstract Classes whose method implementations are
deferred to sub-classes
– Important concept in OO
– Requires own key-word abstract
– No instance of an abstract class can be generated
The University of Sydney Page 7
Interfaces
– Java has no multi-inheritance
– Interface is a way-out (introduction of multi-inheritance via the back-door)
– Interfaces is a class contract that ensures that a class implements a set of
methods.
– Interfaces can inherit from other interfaces
– Ensures that a class has a certain set of behavior
– Interfaces are specified so that they form a directed acyclic graph
– Methods declared in an interface are always public and abstract
– Variables are permitted if they are static and final only
The University of Sydney Page 8
Example: Interface
// definition of interface
public interface A {
int foo(int x);
}
// class X implements interface A
class X implements A {
int foo(int x) {
return x;
}
}
The University of Sydney Page 9
Example: Interface
– Inheritance in interfaces
– Interface B has methods foo() and hoo()
// definition of interface
public interface A {
int foo(int x);
}
public interface B extends A{
int hoo(int x);
}
The University of Sydney Page 10
Virtual Dispatch
– Methods in Java permit a late binding
– Reference variable and its type does not tell which method is
really invoked
– The type of reference variable and class instance may differ
– Class variables may override methods of super classes
– The method invoked is determined by the type of the class
instance
– Binding is of great importance to understand OO
The University of Sydney Page 11
Example: Virtual Dispatch
– Example:
public class Shape extends Object {
double area() { }
}
public class Rectangle extends Shape {
double area() { }
}
…
Shape X = new Shape();
Shape Y = new Rectangle();
double a1 = X.area() // invokes area of Shape
double a2 = Y.area() // invokes area of Rectangle
The University of Sydney Page 12
OO Design Principles
Revisit
.
The University of Sydney Page 13
GRASP: Methodological Approach to OO Design
General Responsibility Assignment Software Patterns
The five basic principles:
• Creator
• Information Expert
• High Cohesion
• Low Coupling
• Controller
The University of Sydney Page 19
Dependency
– A dependency exists between two elements if changes to the
definition of one element (the supplier) may cause changes to
the other (the client)
– Various reason for dependency
– Class send message to another
– One class has another as its data
– One class mention another as a parameter to an operation
– One class is a superclass or interface of another
The University of Sydney Page 20
Coupling
– How strongly one element is connected to, has knowledge of, or
depends on other elements
– Illustrated as dependency relationship in UML class diagram
A
E
B
C
DF
The University of Sydney Page 21
GRASP: Low Coupling Principle
Problem
How to reduce the impact of change, to support low dependency, and increase reuse?
Solution
Assign a responsibility so that coupling remains low
The University of Sydney Page 22
Cohesion
– How strongly related and focused the responsibilities of an
element are
– How to keep objects focused, understandable, and
manageable, and as a side effect, support Low Coupling?
– Assign responsibilities so that cohesion remains high
The University of Sydney Page 25
OO Design Principles
– Separate aspects of your application that vary from what does not change
– Program to an interface not an implementation
– Behavior delegation
– Composition vs Inheritance
– Composition provides a lot of flexibility and change the behavior at runtime
(the object you’re composing with implements the correct behavior interface)
– Quality of OO designs are evaluated based on reusability, extensibility,
and maintainability
The University of Sydney Page 29
Design Patterns Review
Revisit
Slides from SOFT2201
The University of Sydney Page 30
Catalogue of Design Patterns
Design Pattern Description
Gang of Four (Gof) First and most used. Fundamental patterns OO development, but not
specifically for enterprise software development.
Enterprise Application
Architecture (EAA)
Layered application architecture with focus on domain logic, web,
database interaction and concurrency and distribution. Database
patterns (object-relational mapping issues)
Enterprise Integration Integrating enterprise applications using effective messaging models
Core J2EE EAA Focused on J2EE platform. Applicable to other platforms
Microsoft Enterprise
Solution
MS enterprise software patterns. Web, deployment and distributed
systems
https://martinfowler.com/articles/enterprisePatterns.html
https://martinfowler.com/articles/enterprisePatterns.html
The University of Sydney Page 31
Catalogue of Design Patterns
Design Pattern Description
Microsoft
Integration
Microsoft view on integration layer, system connections and
topologies for integration
Data Model Common patterns for data modelling and useful for object
modelling
Microsoft Data Patterns on data movement; replication and synchronization
https://martinfowler.com/articles/enterprisePatterns.html
https://martinfowler.com/articles/enterprisePatterns.html
The University of Sydney Page 32
Aspects of Enterprise Software
– Enterprise Application Architecture
– EAA typical structured into logical layers
– Some differences but some common aspects
– Technology independent/dependent
– Patterns of EAA
– Technology independent
– Core J2EE
– J2EE context
– Microsoft Enterprise Solution Patterns
– .NET views
The University of Sydney Page 33
Aspects of Enterprise Software
– Enterprise Integration
– EA developed independently but needs to work together
– Integration was not considered, or dependent on certain technology
– Enterprise Integration Patterns
– messaging
– Microsoft Integration Patterns
– strategies
– Microsoft Data Patterns
– replication and synchronization
The University of Sydney Page 34
Aspects of Enterprise Software
– Domain Logic
– Business rules, validations and computations
– Some systems intrinsically have complex domain logic
– Regular changes as business conditions change
– EAA Patterns
– organizing domain logic
– Data Model Patterns
– Data modeling approach with examples of domains
The University of Sydney Page 35
SOFT3202 / COMP93202
– GoF Patterns
– Flyweight, Bridge, Chain of Responsibility
– Concurrency
– Lock, Thread Pool
– Enterprise
– Lazy load, Value Object, Unit of Work (,MVC, SOA)
The University of Sydney Page 36
Review of GoF Design
Patterns
The University of Sydney Page 37
Design Patterns
– Proven solutions to general design problems which can be applied to
specific applications
– Not readily coded solution, but rather the solution path to a common
programming problem
– Design or implementation structure that achieves a particular purpose
– Allow evolution and change
– Vary independently of other components
– Provide a shared language among development communities – effective
communication
The University of Sydney Page 38
Elements of a Pattern
– The pattern name
– The problem
– When to apply the pattern
– The solution
– The elements that make up the design
– Consequence
– The results and trade-offs of applying the pattern
The University of Sydney Page 39
Gang of Four Patterns (GoF)
• Official design pattern reference
• Famous and influential book about design patterns
Recommended for students who wish to become
experts
We will cover the most widely – used patterns from
the book
• Many other patterns but not all so popular
• GoF Design Patterns → Design Patterns
The University of Sydney Page 40
Design Patterns – Classification
Scope / Purpose Creational Structural Behavioral
Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
The University of Sydney Page 41
Design Patterns – Classification
Describes of 23 design patterns
– Creational patterns
– Abstract the instantiation process
– Make a system independent of how its objects are created, composed
and represented
– Structural patterns
– How classes and objects are composed to form larger structures
– Behavioral patterns
– Concerns with algorithms and the assignment of responsibilities between
objects
The University of Sydney Page 43
Selecting Appropriate Design Pattern
– Consider how design pattern solve a problem
– Read through Each pattern’s intent to find relevant ones
– Study the relationship between design patterns
– Study patterns of like purpose (similarities and differences)
– Examine a cause of redesign (what might force a change to a design? Tight-
coupling, difficult to change classes
– Consider what should be variable in your design (see table in next slides)
The University of Sydney Page 44
Design Aspects Can be Varied by Design Patterns
Purpose Pattern Aspects that can change
Creational
Abstract Factory
Builder
Factory Method
Prototype
Singleton
families of product objects
how a composite object gets created
subclass of object that is instantiated
class of object that is instantiated
the sole instance of a class
Structural
Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
interface to an object
implementation of an object
structure and composition of an object
responsibilities of an object without subclassing
interface to a subsystem
storage costs of objects
how an object is accessed; its location
The University of Sydney Page 45
Design Aspects Can be Varied by Design Patterns
Purpose Pattern Aspects that can change
Behavioral
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
object that can fulfill a request
when and how a request is fulfilled
grammar and interpretation of a language
how an aggregate’s elements are accessed, traversed
how and which objects interact with each other
what private info. is stored outside an object, & when
number of objects that depend on another object; how the
dependent objects stay up to date
states of an object
an algorithm
steps of an algorithm
operations that can be applied to object(s) without changing
their class(es)
The University of Sydney Page 46
Creational Patterns
The University of Sydney Page 47
Creational Patterns
– Abstract the instantiation process
– Make a system independent of how its objects are created, composed and
represented
– Class creational pattern uses inheritance to vary the class that’s instantiated
– Object creational pattern delegates instantiation to another object
– Becomes more important as systems evolve to depend on object composition
than class inheritance
– Provides flexibility in what gets created, who creates it, how it gets created
and when
– Let you configure a system with “product” objects that vary in structure and functionality
The University of Sydney Page 48
Creational Patterns
Pattern Name Description
Abstract Factory Provide an interface for creating families of related or dependent objects
without specifying their concrete classes
Singleton Ensure a class only has one instance, and provide global point of access to it
Factory Method Define an interface for creating an object, but let sub-class decide which
class to instantiate (class instantiation deferred to subclasses)
Builder Separate the construction of a complex object from its representation so that
the same construction process can create different representations
Prototype Specify the kinds of objects to create using a prototype instance, and create
new objects by copying this prototype
See Additional Review Slides: https://canvas.sydney.edu.au/courses/14614/pages/lecture-review-of-design-patterns?module_item_id=437271
https://canvas.sydney.edu.au/courses/14614/pages/lecture-review-of-design-patterns?module_item_id=437271
The University of Sydney Page 49
Factory Method
– Intent
– Define an interface for creating an object, but let subclasses decide which class
to instantiate. Let a class defer instantiation to subclasses
– Also known as
– Virtual Constructor
– Applicability
– A class cannot anticipate the class objects it must create
– A class wants its subclasses to specify the objects it creates
– Classes delegate responsibility to one of several helper subclasses, and you
want to localize the knowledge of which helper subclass is the delegate
The University of Sydney Page 50
Factory Method Pattern – Structure
The University of Sydney Page 51
Factory Method Pattern – Participants
– Product
– Defines the interface of objects the factory method creates
– ConcreteProduct
– Implements the Product interface
– Creator
– Declares the factory method, which returns an object of type Product. Creator
may also define a default implementation of the factory method that returns a
default ConcreteProduct object
– May call the factory method to create a Product object
– ConcreteCreator
– Overrides the factory method to return an instance of a Concrete Product
The University of Sydney Page 53
Abstract Factory
Object Creational
The University of Sydney Page 54
Abstract Factory Pattern
– Intent
– Provide an interface for creating families of related or dependent objects
without specifying their concrete classes
– Also known as
– Kit
– Applicability
– A system should be independent of how its products are created, composed and
represented
– A system should be configured with one of multiple families of products
– Family of related product objects is designed to be used together and you need
to enforce this constraint
– You want to provide a class library of products, and you want to reveal just their
interfaces, not their implementation
The University of Sydney Page 55
Abstract Factory
– Structure
The University of Sydney Page 56
Abstract Factory Pattern – Participants
– AbstractFactory
– Declares an interface for operations that create abstract product objects
– ConcreteFactory
– Implements the operations to create concrete product objects
– AbstractProduct
– declares an interface for a type of product object
– ConcreteProduct
– defines a product object to be created by the corresponding concrete factory
– Implements the AbstractProduct interface
– Client
– uses only interfaces declared by AbstractFactory and AbstractProduct classes.
The University of Sydney Page 57
Abstract Factory – POS
– Problem
– Now we have a series of
adapters for all sorts of
different external services
– Who should be responsible
for creating the correct set?
CATaxAdapter
getTaxes( Sale ) : List of TaxLineItems
MATaxAdapter
getTaxes( Sale ) : List of TaxLineItems
«interface»
ITaxCalculatorAdapter
getTaxes( Sale ) : List of TaxLineItems
SAPAccountingAdapter
postReceivable( CreditPayment )
postSale( Sale )
…
GreatNorthernAccountingAdapter
postReceivable( CreditPayment )
postSale( Sale )
…
«interface»
IAccountingAdapter
postReceivable( CreditPayment )
postSale( Sale )
…
«interface»
IInventoryAdapter
…
«interface»
ICreditAuthorizationService
Adapter
requestApproval(CreditPayment,TerminalID, MerchantID)
…
The University of Sydney Page 58
Abstract Factory – POS
– Suppose the POS is deployed in some stores in MA, we’ll need
– MATaxAdapter, GreatNorthenAccountingAdapter, …
– If it is deployed in CA, we’ll need
– CATaxAdapter, SAPAccountingAdapter
The University of Sydney Page 59
Abstract Factory – POS
– We need several factory objects each will be responsible for creating a set of
objects
– A MAFactory which will create MATaxAdapter,
GreatNorthemAccountingAdapter and so on
– A CAFactory which will create CATaxAdapter, SAPAccountingAdapter
and so on
– Naturally we’ll have an abstraction which is an Abstract Factory
The University of Sydney Page 60
Abstract Factory – POS
+makeTaxAdapter()
+makeAccountingAdapter()
MAFactory
+makeTaxAdapter()
+makeAccountingAdapter()
CAFactory
class MAFactory{
public ITaxCalculatorAdapter makeTaxAdapter(){
return new MATaxAdapter();
}
public IAccountingAdapter makeAccountingAdapter(){
return new GreatNorthenAccountingAdapter();
}
..
}
class CAFactory{
public ITaxCalculatorAdapter makeTaxAdapter(){
return new CATaxAdapter();
}
public IAccountingAdapter makeAccountingAdapter(){
return new SAPAccountingAdapter();
}
..
}
+makeTaxAdapter()
+makeAccountingAdapter()
ServiceFactory abstract class Serviceactory{
public abstract ITaxCalculatorAdapter makeTaxAdapter();
public abstract IAccountingAdapter makeAccountingAdapter();
}
The University of Sydney Page 61
Abstract Factory – Structure (NextGen POS
– AbstractFactory (ServiceFactory)
– declares an interface for operations that create
abstract products
– ConcreteFactory (MAFactory, CAFactory)
– implements the operations to create concrete
product objects
– AbstractProduct (IAccountingAdapter,
ITaxCalculatorAdpter)
– declares an interface for a type of product object
– Product (MATaxAdapter, CATaxAdapter,
SAPAccountingAdapter,
GreatNorthernAccountingAdapter)
– defines a product object to be created by the
corresponding concrete factory
– implements the AbstractProduct interface
– Client (Store)
– uses interfaces declared by AbstractFactory and
AbstractProduct classes
The University of Sydney Page 62
Other Creational Patterns
Pattern Name Description
Abstract Factory Provide an interface for creating families of related or dependent objects
without specifying their concrete classes
Singleton Ensure a class only has one instance, and provide global point of access to it
Factory Method Define an interface for creating an object, but let sub-class decide which
class to instantiate (class instantiation deferred to subclasses)
Builder Separate the construction of a complex object from its representation so that
the same construction process can create different representations
Prototype Specify the kinds of objects to create using a prototype instance, and create
new objects by copying this prototype
See Additional Review Slides: https://canvas.sydney.edu.au/courses/14614/pages/lecture-review-of-design-patterns?module_item_id=437271
https://canvas.sydney.edu.au/courses/14614/pages/lecture-review-of-design-patterns?module_item_id=437271
The University of Sydney Page 63
Structural Patterns
The University of Sydney Page 64
Structural Patterns
– How classes and objects are composed to form larger structures
– Structural class patterns use inheritance to compose interfaces or
implementations
– Structural object patterns describe ways to compose objects to realize new
functionality
– The flexibility of object composition comes from the ability to change the
composition at run-time
The University of Sydney Page 65
Structural Patterns (GoF)
Pattern Name Description
Adapter Allow classes of incompatible interfaces to work together. Convert the
interface of a class into another interface clients expect.
Façade Provides a unified interface to a set of interfaces in a subsystem. Defines a
higher-level interface that makes the subsystem easier to use.
Composite Compose objects into tree structures to represents part-whole hierarchies. Let
client treat individual objects and compositions of objects uniformly
Proxy Provide a placeholder for another object to control access to it
Decorator Attach additional responsibilities to an object dynamically (flexible
alternative to subclassing for extending functionality)
Bridge Decouple an abstraction from its implementation so that the two can vary
independently
Flight weight Use sharing to support large numbers of fine-grained objects efficiently
The University of Sydney Page 66
Adapter
– Intent
– Convert the interface of a class into another interface clients expect
– Lets classes work together that couldn’t otherwise because of
incompatible interfaces
– Applicability
– To use an existing class, and its interface does not match the one you need
– You want to create a reusable class that cooperates with unrelated or
unforeseen classes, i.e., classes that don’t necessarily have compatible interfaces
– Object adapter only to use several existing subclasses, but it’s unpractical to
adapt their interface by sub-classing every one. An object adapter can adapt
the interface of its parent class.
The University of Sydney Page 68
Object Adapter – Structure
The University of Sydney Page 69
Adapter – Participants
– Target
– Defines the domain-specific interface that Client uses
– Client
– Collaborates with objects conforming to the Target interface.
– Adaptee
– Defines an existing interface t hat needs adapting.
– Adapter
– Adapts the interface of Adaptee to the Target interface
– Collaborations
– Clients call operations on an Adapter instance. In turn, the adapter calls Adaptec
operations that carry out the request
The University of Sydney Page 73
Object Adapter – Consequences
– Lets a single Adapter work with many Adaptees – i.e., the Adaptee itself
and all of its subclasses (if any). The Adapter can also add functionality to all
Adaptees at once
– Makes it harder to override Adaptee behavior. It will require sub-classing
adaptee and making Adapter refer to the subclass rather than the Adaptee
itself
The University of Sydney Page 75
Adapter in POS – Requirements
– Next Gen PoS system needs to
communicate with several external
third-party services
– Tax calculators, credit authorization
services, inventory systems,
accounting systems.
– Each has a different API and can not
be changed.
NextGen
Manage Users
. . .
Cashier
System
Administrator
actor
use case
communicationsystem boundary
Handle Returns
Payment
Authorization
Service
«actor»
Tax Calculator
«actor»
Accounting
System
alternate
notation for
a computer
system actor
Process Rental
«actor»
HR System
Cash In
Process Sale
«actor»
Sales Activity
System
Manage Security
Analyze Activity
Outside the system boundary
and developed and maintained by third parties
The University of Sydney Page 77
Adapter in POS – Reality
– Consider the TaxCalculator services
– Suppose the POS system will be installed through out the country
– Each state has its own way of calculating and collecting tax
• California: 8.5% on almost everything
• Mass: 5% on most items except grocery
– Each state has its own TaxCalculator service (as a jar perhaps)
• California API: List getTaxes (List allItem)
• Mass API: Set computeTaxes (Set allItem)
The University of Sydney Page 78
Requirements – Business Rules
– Business rule (domain rule)
– Dictate how a domain or business may operate
– Not restricted by a particular application
– May apply to many applications in the same domain
– Company policies, physical laws and government laws
– Example:
ID Rule Changeability Source
RULE1 Tax rules. Sales require
added taxes. (POS domain)
High. Tax laws change
annually, at all government
levels
law
The University of Sydney Page 80
Adapter in POS – First Attempt
– Novice (straightforward) design of Sale.getTaxes method
List getTaxes (){
…
switch (state){
case CA:
CATax catax = new CATax();
List taxlineitem = catax.getTaxes (lineItems);
break;
case MA:
MATax matax = new MATax();
List taxlineitem = new ArrayList(matax.computeTaxes (
new HashSet(lineItems))); // type conversion required
break;
…
}
The University of Sydney Page 81
Adapter in POS – Solution
– How to make the Sale object decoupled from detailed Tax Calculation services
– Reason: Sale is interested in getting the tax for each taxable item, not how taxes are
calculated in different states
– Solution:
• Sale defines an interface to get results on taxes
– ITaxCalculatorAdapter
• Any Tax Calculation Service that does not use this interface needs to find a interpreter
(Adapter) to do the translation
– MassTaxAdapter, CATaxAdapter
The University of Sydney Page 82
Adapter in POS – Solution
MassTaxAdapter
getTaxes( Sale ) : List of TaxLineItems
CATaxAdapter
getTaxes( Sale ) : List of TaxLineItems
«interface»
ITaxCalculatorAdapter
getTaxes( Sale ) : List of TaxLineItems
Adapter
…
…
+computeTaxes()
MATax
11
+getTaxes()
CATax
class MassTaxAdapter{
private MATax matax = newMATax();
public List getTaxes (Sale sale){
Set salesLineItem = new HashSet
(sale.getSalesLineItem);
Set temSet = matax.computeTaxes(salesLineItem);
return new ArrayList(tempSet)
}
11
Sale
*
1
The University of Sydney Page 83
The new Sale class
class Sale{
List taxLineItem;
…
List
ITaxCalculatorAdapter tca = …;
return tca.getTaxes(this);
}
…
}
The University of Sydney Page 91
Façade Pattern
Object Structural
The University of Sydney Page 92
Façade Pattern
– Intent
– Provide a unified interface to a set of interfaces in a subsystem. It defines a
higher-level interface that makes the subsystem easier to use
– Applicability
– You want to provide a simple interface to a complex subsystem
– There are many dependencies between clients and the implementation classes
of an abstraction
– You want to layer your subsystem. Façade would define an entry point to each
subsystem level
The University of Sydney Page 93
Façade Motivation
A facade object provides a single, simplified interface to the more general facilities of a
subsystem
The University of Sydney Page 94
Façade – Structure
The University of Sydney Page 95
Façade – Participants
– Facade
– Knows which subsystem classes are responsible for a request.
– Delegates client requests to appropriate subsystem objects.
– Subsystem classes
– Implement subsystem functionality.
– Handle work assigned by the Façade object
– Have no knowledge of the facade; they keep no references to it.
– Collaborations
– Clients communicate with the subsystem by sending requests to Façade, which forwards
them to the appropriate subsystem object(s).
• Although the subsystem objects perform the actual work, the façade may have to
do work of its own to translate its interface to subsystem interfaces
– Clients that use the facade don’t have to access its subsystem objects directly
The University of Sydney Page 96
Consequences
– Simplify the usage of an existing subsystem by defining your own interface
– Shields clients from subsystem components, reduce the number of objects that clients
deal with and make the subsystem easier to use.
– Promote weak coupling between the subsystem and the clients
– Vary the components of the subsystem without affecting its clients
– Reduce compilation dependencies (esp. large systems) – when subsystem classes change
– Does not prevent applications from using subsystem classes if they need to. Choice
between ease of use and flexibility.
The University of Sydney Page 97
Façade – NextGen POS
– Pluggable business rules in POS (iteration 2 requirements)
– Consider rules that might invalidate an action at certain point
– When a new sales is created:
• Business rule 1: if it will be paid by a gift card, only one item is allowed to
be purchased. Invalidate all requests of entering another item.
– When a payment is made by gift certificate:
• Business rule 2: balance should due back in another gift certificate.
Invalidate all requests of giving customer change either in cash or credit
card.
The University of Sydney Page 98
Façade – NextGen POS Business Rules
– Each store that would deploy PoS system will have different business rules
implemented differently
– Not desirable to scatter the implementation of business rules all over the system
• Consequence: for each installation of POS system, need to modify lots of classes
– We want a design that has low impact on the existing software components.
• Factor out all rules in a separate subsystem to localize the change.
The University of Sydney Page 100
Façade in POS system
– Use an façade object POSRuleEngineFacade to communicate with the
business rule subsystem
– Façade object is usually implemented as Singleton
public class sale{
public void makeLineItem(ProductDescription desc, int quantity){
SalesLineItem sli = new SalesLineItem (desc, quantity);
// call to
