OO Design

1
OO Design

• Roshan Chitrakar

2
Analysis to Design

• Do the RIGHT thing
• Requirement Analysis
• Domain Modeling with addition of attributes and
  associations
• Use Case Modeling (Behavioral modeling)
• Requisite Pro and Use case diagrams

• Do the thing RIGHT
• Responsibility assignment
• Object Design
• Design Class diagrams
• Determining visibility
• Interaction diagrams (Sequence diagrams
  Collaboration diagrams, Class diagram)

3
OO Design Introduction

• A logical solution based on OO paradigm is
  developed
• Constitutes a design model
• Creation of Interaction diagrams (collaboration
  among objects and/or sequence of messages)
• Class diagrams are drawn in parallel with or
  after the interaction diagrams

4
GRASP

• Fundamental principles of Object design are -
• Responsibility assignment and
• Design patterns
• GRASP (General Responsibilities Assignment
  Software Patterns) describe the principles of
  object design and responsibility assignment,
  expressed as patterns.

5
Responsibility

• It is a contract or obligation of a classifier
• It is assigned to classes during object design
• Type of Responsibilities
• Knowing (e.g. a Sale is responsible for knowing
  its total)
• about private encapsulated data
• about related objects
• about things it can derive or calculate
• Doing (e.g. a Sale is responsible for creating
  SalesLineItems)
• something itself
• initiating action in other objects
• controlling and coordinating activities in other
  objects

6
Methods

• Responsibilities are translated into methods
• Depending upon the granularity, several methods
  are implemented to fulfill the responsibilities
• Methods either act alone or collaboratively
• Both responsibilities and methods are reflected
  in interaction diagrams

7
Responsibility Methods in Interaction Diagram
Responsibility To create Payments
8
Patterns

• A pattern is a named problem/solution pair that
  can be applied in new context, with advice on how
  to apply it in novel situation and discussion of
  its trade-offs.e.g.Pattern Name Information
  ExpertSolution Assign a responsibility to the
  class that has the information needed to fulfill
  it.Problem It Solves What is a basic principle
  by which to assign responsibilities to objects.

9
The First Five GRAS Patterns

• They are -
• Information Expert (or Expert)
• Creator
• High Cohesion
• Low Coupling
• Controller
• They cover very basic, common and fundamental
  design issues

10
Information Expert

• It guides that objects do things related to the
  information they have.
• It is a class that has information necessary to
  fulfill the responsibility
• There may have partial information experts who
  will collaborate for the responsibility

Design Class Responsibility
Sale Knows sale total
SalesLineItem Knows line item subtotal
ProductSpecification Knows product price
11
Expert Illustration To find out the grand total
Domain model showing association of Sale
12
Expert Illustration To find out the grand total

• More than one class can act as information
  expert.
• They collaborate by passing messages.

• Knowing Line Item sub total and knowing product
  price in order to get the grand total.
• Responsibilities are being added to both
  interaction and Class diagrams also.

13
Expert Pro and Cons

• Advantages -
• Encapsulation is maintained
• Behavior is distributed across the classes
• Disadvantages -
• Leads to problems of coupling, cohesion and
  duplication

14
Creator

• It guides assigning responsibilities related to
  the creation of objects
• The concept of aggregation is the basic guiding
  principle of the Creator.
• It suggests that the enclosing container or
  recorder class is a good candidate for the
  responsibility

15
Creator Illustration Creating a Sales Line Item
Sale Domain
16
Creator Illustration Creating a Sales Line Item
17
Creator Pro and Cons

• Benefits -
• Low coupling is supported i.e lower maintenance
  dependence and higher possibility of reuse.
• Contraindications -
• In special cases, all creations are delegated to
  a helper class called Factory. (Which is against
  the principle of Creator)

18
Low Coupling

• It suggests assigning a responsibilities to
  classes such that their placement does not
  produce negative results.
• It recommends designs of classes to be more
  independent and hence reduce the impacts of
  change.
• No absolute measure of low/high coupling,
  designer has to assess it so that negative
  results would not occur.

19
Low Coupling Illustration Creating a Payment
Creator pattern suggests Register as a candidate
for creating the Payment.
Coupling of Register class to the knowledge of
Payment class
20
Low Coupling Illustration Creating a Payment
An alternate solution Coupling of Sale class
with the Payment class
Sale creates the Payment does not increase the
coupling
21
High Cohesion

• High functional cohesion exists when the
  elements of a component (e.g. a class) all work
  together to provide some well-bounded
  behavior - Booch
• High Cohesion has fewer methods, with highly
  related functionality, collaborates with other
  objects to share the effort.
• High Cohesion pattern has real world analogy or
  delegating the too much work.

22
High Cohesion Illustration Creating a Payment
Register creates the Payment by taking the work
by itself Low cohesion
23
High Cohesion Illustration Creating a Payment
Register delegates the work to Sale Low cohesion
24
High Cohesion Pro and Cons

• Advantages -
• Maintenance and enhancement is simplified
• Low coupling is often supported
• Reuse is increased.
• Disadvantages -
• Distributed servers take more overhead and pay
  reduced performance
• For only one person to maintain and support the
  component, it is difficult.

25
Controller

• It provides guidance for handlers for external
  inputs / events messages or signals that system
  receives.
• It delegates, coordinates and controls the work
  to other objects does not do the actual work.
• The System class made during the analysis phase,
  is now taken care of by Controller class.

26
System Class to Controller Class
Register acts as the single Controller Class
Two handlers act like Controllers
27
Controller Illustration enterItem()
28
Controller Illustration enterItem()
Possible handlers are -
29
Controller Pro and Cons

• Increased potential for reuse
• Pluggable interface (i.e. application logic is
  not handled in the interface layer)
• It guarantees that system operations within a use
  case occur in a legal sequence (It is possible if
  the same controller is used throughout the use
  case)