The document discusses coupling and the Law of Demeter principle, which states that objects should only communicate with their immediate neighbors. Following this principle leads to code with looser coupling, better encapsulation, and easier substitution of components. The document provides examples of correct and incorrect ways to follow the Law of Demeter when sending messages to instance variables, arguments, self, and newly created objects. It also discusses some exceptions like collections, as well as considerations around using accessors instead of direct instance variable access. Overall it emphasizes designing objects with complete interfaces that protect encapsulation.

1. Stéphane Ducasse 1
Stéphane Ducasse
stephane.ducasse@inria.fr
http://stephane.ducasse.free.fr/
Design Points - Law of
Demeter
Stéphane Ducasse --- 2005

2. S.Ducasse 2
About Coupling
• Why coupled classes is fragile design?
• Law of Demeter
• Thoughts about accessor use

3. S.Ducasse 3
Coupling hampers...
Reuse
I cannot reuse this component in another application
Substitution
I cannot substitute easily this component for another one
Encapsulation
When a far away change happens, I get impacted

4. S.Ducasse 4
The Core of the Problem

5. S.Ducasse 5
The Law of Demeter
You should only send messages to:
an argument passed to you
instance variables
an object you create
self, super
your class
Avoid global variables
Avoid objects returned from message sends other
than self

6. S.Ducasse 6
Correct Messages
someMethod: aParameter
self foo.
super someMethod: aParameter.
self class foo.
self instVarOne foo.
instVarOne foo.
aParameter foo.
thing := Thing new.
thing foo

7. S.Ducasse 7
In other words
• Only talk to your immediate friends.
• In other words:
• You can play with yourself. (this.method())
• You can play with your own toys (but you can't take them
apart). (field.method(), field.getX())
• You can play with toys that were given to you. (arg.method())
• And you can play with toys you've made yourself. (A a =
new A(); a.method())

8. S.Ducasse 8
Halt!

9. S.Ducasse 9
To not skip your intermediate

10. S.Ducasse 10
Solution

11. S.Ducasse 11
Transformation

12. S.Ducasse 12
Heuristic of Demeter
Not a law
Know when you can bend it or not apply it
Encapsulating collections may produce large
interfaces so not applying the LoD may help.

13. S.Ducasse 13
Collections
Object subclass: #A
instVar: myCollection
A>>do: aBlock
myCollection do: aBlock
A>>collect: aBlock
^ myCollection collect: aBlock
A>>select: aBlock
^ myCollection select: aBlock
A>>detect: aBlock
^ myCollection detect: aBlock
A>>isEmpty
^ myCollection isEmpty
…………………

14. S.Ducasse 14
About the Use of Accessors
Some schools say:“Access instance variables using
methods”
In such a case
Be consistent inside a class, do not mix direct access and
accessor use
Think accessors as protected methods (not invoked by
clients)
in ST: put them in accessing only when public

15. S.Ducasse 15
Accessors
Accessors are good for lazy initialization
Scheduler>>tasks
tasks isNil ifTrue: [task := ...].
^ tasks
BUT accessors methods should be Protected by
default at least at the beginning

16. S.Ducasse 16
Example
Scheduler>>initialize
self tasks: OrderedCollection new.
Scheduler>>tasks
^ tasks
But now everybody can tweak the tasks!

17. S.Ducasse 17
Accessors open Encapsulation
The fact that accessors are methods doesn’t
support a good data encapsulation.
You could be tempted to write in a client:
ScheduledView>>addTaskButton
...
model tasks add: newTask
What’s happen if we change the representation of
tasks?

18. S.Ducasse 18
Tasks
If tasks is now an array, it will break
Take care about the coupling between your objects
and provide a good interface!
Schedule>>addTask: aTask
tasks add: aTask
ScheduledView>>addTaskButton
...
model addTask: newTask

19. S.Ducasse 19
About Copy Accessor
Should I copy the structure?
Scheduler>>tasks
^ tasks copy
But then the clients can get confused...
Scheduler uniqueInstance tasks removeFirst
and nothing happens!

20. S.Ducasse 20
You will read code
Code that others wrote
Code that you wrote and forgot

21. S.Ducasse 21
Use intention revealing names
Probably Better
Scheduler>>taskCopy or copiedTasks
“returns a copy of the pending tasks”
^ task copy

22. S.Ducasse 22
Provide a Complete Interface
Workstation>>accept: aPacket
aPacket addressee = self name
…
It is the responsibility of an object to offer a
complete interface that protects itself from client
intrusion.
Shift the responsibility to the Packet object
Packet>>isAddressedTo: aNode
^ addressee = aNode name
Workstation>>accept: aPacket
(aPacket isAddressedTo: self)
ifTrue:[Transcript show: 'A packet is accepted by the
Workstation ', self name asString]