Your SlideShare is downloading. ×
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Stoop ed-lod
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Stoop ed-lod

310

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
310
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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]

×