Coupling, Cohesion, and the Law of Demeter

1
Coupling, Cohesion, and the Law of Demeter

• By Rick Mercer with help from
• Object-Oriented Design Heuristics, Arthur Riel
• Addison-Wesley, 1996, ISBN 0-201-6338-X
• and
• Applying UML and Patterns An Introduction to
  Object-Oriented Analysis and Design and Iterative
  Development, Craig LarmanThird Edition, Pearson
  PTR, October 2004

2
Outline

• Coupling
• Cohesion
• Law of Demeter
• Growing large systems, the good, the bad, and the

3
Low Coupling (good)

• Coupling A measure of how strongly one class is
  connected to, has knowledge of, or relies upon
  other classes
• Low coupling the class is not dependent on too
  many other classes, this is good
• High Coupling class is dependent on many others
• Change in one class could force changes in others
• Harder to understand in isolation
• Harder to reuse
• Guideline Assign responsibilities so that
  coupling remains low

4
Coupling con.

• One class is coupled to another one if it uses
  the others methods functions and/or instance
  variables
• Coupling happens
• Some coupling is necessary and good
• Should be limited when possible
• Can reduce coupling by using the law of Demeter
  (discussed later) which allows only good coupling

5
Which is the better design?

• POST records an instance of Payment, Creator
  guideline suggests that POST constructs Payment
• Then POST asks Sale to add the new payment
• POST is coupled to Payment
• With this design, POST needs to know 2 classes

makePayment()
1 create()
POST
p Payment
2 addPayment(p)
Sale
6
An alternative design

• Associate Payment with Sale
• In both designs, Sale is coupled to Payment
• Low coupling favors this 2nd design

makePayment()
1 makePayment()
POST
Sale
1.1. create()
Payment
7
Discussion

• Low coupling is good
• Common forms of coupling
• Class B has an instance of Class X
• Class B has a method that references an instance
  of Class X
• Class B is a subclass of Class X
• Class B implements Interface X
• Coupling occurs in all programs!

8
Inheritance is strong Coupling

• Choose inheritance carefully
• This is strong coupling
• Hard to say what high coupling is
• Will have some coupling instance variables, one
  object asks another for help, ...

9
High Cohesion (good)

• Cohesion A measure of how strongly related and
  focused the responsibilities of a class are
• High functional cohesion is good
• Low cohesion can be bad
• hard to understand
• hard to reuse
• hard to maintain
• fragile constantly affected by change
• Assign responsibilities so cohesion remains high

10
Cohesion

• Read about Cohesion
• http//en.wikipedia.org/wiki/Cohesion_28computer_
  science29
• Example

11
Reconsider need to create Payment

• In the first design, the Point of Sale Terminal
  (POST) appears to be doing little, so this is
  okay
• But when POST takes on more tasks, it could get
  bloated and increasingly incohesive
• Imagine POST doing 20 tasks
• The design above is a path towards lower cohesion

12
Design 2

• An alternative assigns the responsibility of
  creating the Payment to Sale, not POST
• This design supports lower coupling and higher
  cohesion
• These guidelines shouldn't be considered in
  isolation

13
Cohesion

• Signs of high cohesion (good)
• 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
• All methods and data seem to belong together
• Simpler to understand

14
Law of Demeter

• A style rule for designing object-oriented
  systems
• "Only talk to your immediate friends"
• Name of the Greek Goddess of Agriculture
• In other words, grow software in small steps
• Each module should have only limited knowledge
  about other modules
• Those "closely" related to the current unit
• Each module only talks to friends
• Don't talk to strangers

15
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

16
Who are 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

17
FRIENDS
18
An Example

• Widely used in big projects, for example, at JPL
  for the Mars exploration software, the quote
• The Law of Demeter has taken a firm hold in
  many areas of JPL. Major systems which have used
  LoD extensively include Mars Pathfinder
  Software (begun in 1993). We are going to use LoD
  as a foundational software engineering principle
  for the X2000 Europa orbiter mission.

19
Grady Booch Quote

• The basic effect of applying this Law is the
  creation of loosely coupled classes, whose
  implementation secrets are encapsulated. Such
  classes are fairly unencumbered, meaning that to
  understand the meaning of one class, you need not
  understand the details of many other classes.

20
Violation of LoD

• class B
• public C c
• class C
• public void foo()
• class P
• public Q q()
• return null
• class Q
• public void bar()

21
Violation

• class A
• private B b new B()
• public void m()
• this.b.c.foo() // High coupling, bad
• this.p().q().bar() // High coupling, bad
• public P p()
• return null

22
Example Quiz Question

• What code represents the better design, a or b?
  ___
• // a.
• dog.body.tail.wag()
• // b.
• dog.expressHappiness()
• The bad example couples dog to two indirect
  classes DogBody, and DogTail
• The good design couples dog only to the direct
  class DogAnimal