Design Patterns

1
CSC 335 Object-Oriented Programming and Design
Responsibilities Coupling / Cohesion Law of
Demeter Liskov Substitution Principle Dependency
Inversion Principle
2
Responsibility Patterns

• Responsibility Patterns provide techniques for
  centralizing, expanding, and limiting object
  responsibility
• For example, a model tells it's registered set of
  observers that the state of the model changes
• The observers are responsible for correctly
  updating their view of the model
• And the model can rely on a view for user input
• Button click or Move Slider Bar

3
Responsibility Assignment

• Principles for proper assignment of
  responsibilities is an area ripe for improvement
• Here are some principles for the proper
  assignment of responsibilities
• Expert
• Low coupling
• High Cohesion
• Law of Demeter

4
(Information) Expert

• What is most basic, general principle of
  responsibility assignment?
• Assign a responsibility to the object that has
  the information necessary to fulfill it.
• That which has the information, does the work.
• E.g., What software object calculates sales tax?
• What information is needed to do this?
• What object or objects has the majority of this
  information

5
High Cohesion

• Signs of high cohesion
• A class has moderate responsibilities in one
  functional area
• It collaborates with other classes to fulfill
  tasks
• Has small number of methods, highly related
  functionality, doesn't do too much
• Dare we say single responsibility

6
Polymorphism

• How to design for varying, similar cases?
• Assign a polymorphic operation to the family of
  classes for which the cases vary
• Dont use case logic
• E.g., draw()
• Square, Circle, Triangle

7
Pure Fabrication

• Where to assign a responsibility, when the usual
  options based on Expert lead to problems with
  coupling and cohesion, or are otherwise
  undesirable
• Make up an artificial class, whose name is not
  necessarily inspired by the domain vocabulary
• E.g. PrerequisiteChecker

8
Law of Demeter

• Originally formulated as a style rule for
  designing object-oriented systems
• "Only talk to your immediate friends"
• The style rule was discovered at Northeastern
  University in the fall of 1987 by Ian Holland.
• Each unit should have only limited knowledge
  about other units only units "closely" related
  to the current unit
• Each unit only talks to friends Don't talk to
  strangers

9
Law of Demeter

• This is low coupling in software engineering made
  more explicit
• Try to avoid knowing about the structure of
  indirect objects
• Use the direct object that you need to know about
  and let that object talk to indirect objects

10
Closely related friends?

• From a method, messages can be sent to
• this object
• a parameter of the method
• an instance variable of this object
• an object created within the method

11
Controller

• What object in the domain (or application layer)
  receives requests for work from the UI layer?

12
Controller

• Candidates
• An object whose name reflects the use case
• e.g., RentingVideosUCHandler part of Application
  layer
• An object whose name reflects the overall server,
  business, or large-scale entity
• A kind of facade object
• e.g., Store, RentingServer

13
Controller

• Problem Who should be responsible for handling a
  system event a click on a Component
• Solution Assign the responsibility of handling
  system events to one of a class that
• represents the overall system Jukebox
• represents the organization Store
• represents something that is active in the real
  world person's role such as Librarian or
  BankTeller

14
Controllers

• Controllers handle system events
• You probably have a controller that
• Changes views when a menu option is selected
• Starts a new game when a menu option is selected
• It is an instance of a class that can respond to
  system events
• In Java, the listeners

15
Discussion

• External input events include
• users interacting with a GUI
• handling a call in a telecommunications switch
• signals from real time sensors
• In OOD, controllers should handle these events
• In Java the listeners

16
Controllers

• Common Defect
• Controllers get too many responsibilities
• Controllers should delegate responsibility to
  other objects
• Does your controller tell the game of lights
  which lights to turn on?
• The controller (listeners) should not have
  responsibility of performing the business logic
• A listener is not responsible for checking
  prereqs

17
Visibility

• BurnRate example
• You need the burnRate to compute thrust
• thrust is computed in the constructor for a
  SolidRocket
• Your fields are package scope
• Someone subclasses SolidRocket and adds
  setBurnRate, but thrust does not change
• How do you avoid this?

18
Summary

• We assign responsibilities to objects and combine
  attributes with behavior
• Encapsulation Objects work on their own data
• Sometimes need to move responsibilities to an
  intermediary
• Sometimes you may want to observe behavior
  without the object knowing it or decoupled from
  it
• The Observer Pattern