Patterns Tutorial - Answer Notes and Examples

Discuss the following GRAS patterns and answer the questions for each of them

Expert
Problem:
What is the most basic principle by which responsibilities are assigned in object-
oriented design?
Solution? Assign a responsibility to the information expert

POST
Who is responsible for knowing the grand total of a sale in a typical Point of
Sale application? = Sale
Sale

date
time

Contain
s
1.. *
Produc t
Sales Specification
LineItem * Described-
by description
quantity price
UPC

Creator
Problem:
Who should be assigned the responsibility for creating a new instance of some class?
Solution? To keep coupling low, it is preferable that the creator is a class that is
connected to the created class or object.

POST

Who is responsible for creating SalesLineItem objects? = Sale

Sale

date
time

Contain
s
1.. *
Product
Sales Specification
LineItem * Described-
by description
quantity price
UPC
Controller
Problem:
Who should have responsibility for handling system events and separate the view
classes (UIs) from the model classes(such business classes)?
Solution: Assign the responsibility for receiving or handling a system event message to
a class representing the overall system or a use case scenario within which the system
event occurs.

POST

In Buy Items use case there are few system events such:
 enterItem()
 endSale()
 makePayment()
Who has the responsibility for enterItem()? How could a controller class be used in this
situation?
- By controller there will be 4 options which is the overall system(POST),
the overall business(Store), real word actor(Cashier) and use case
handler(BuyItemsHandler). Controller class is responsible for handling
system event message to a class representing the use case scenario
within which the system event occurs.

How can the presentation layer be decoupled from problem domain?

Object Store

UPC Quantity

Total

Tendered Balance

presses button
Enter Item End Sale Make Payment

Cashier

Presentation Layer

Domain Layer :POST 1.1: makeLineItem(upc, qty) :Sale

-Add a command object

 Object Store

UPC Quantity

Total

Tendered Balance

presses button
Enter Item End Sale Make Payment

Cashier

:POSTCommand
Presentation Layer

Domain Layer :POST 1.1: makeLineItem(upc, qty) :Sale

Low Coupling
Problem:
How can a design support low dependency and increased reuse?
Solution: Assign a responsibility so that coupling remains low

POST:

Who has responsibility to create a payment? = Sale

Payment POST Sale

Which one of the 2 possibilities is better? =Sale because Sale has to be coupled to
Payment
a. Post

makePayment() :POST 1: create() p : Payment

2: addPayment(p)
:Sale

b. Sale

makePayment() :POST 1: makePayment() :Sale

1.1. create()

:Payment

 
High Cohesion

Problem:
How a design should keep complexity manageable (regarding cohesion)?
Solution: Assign responsibilities such that cohesion remains high

  
POST
Who should have the responsibility to create a payment so cohesion remains high? = Sale

If POST class makes the payment:

makePayment() :POST 1: create() p : Payment

2: addPayment(p)
:Sale

Or if Sale makes a payment:

makePayment() :POST 1: makePayment() :Sale

1.1. create()

:Payment

Polymorphism

Problem:
To handle alternatives based on types?
Solution: It is possible to use objects of different types If they inherit from the same
abstract class

Give an example of polymorphism to handle payment

By polymorphism, each payment should authorize itself.