Law of Demeter with data model objects

by

There is a book called Clean Code by Robert Martin that covers this.

In Chapter 6 (Objects and Data Structures) he talks about fundamental differences between objects and data structures.
Objects benefit from encapsulation, data structures don’t.

There is a section about the Law of Demeter:

There is a well-known heuristic called the Law of Demeter that says a module should not know about the innards of the objects it manipulates. As we saw in the last section, objects hide their data and expose operations. This means that an object should not expose its internal structure through accessors because to do so is to expose, rather than to hide, its internal structure.

More precisely, the Law of Demeter says that a method f of a class C should only call the methods of these:

  • C
  • An object created by f
  • An object passed as an argument to f
  • An object held in an instance variable of C

The method should not invoke methods on objects that are returned by any of the allowed functions. In other words, talk to friends, not to strangers.

Uncle Bob gives an example of a LoD violation:

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

Whether this is a violation of Demeter depends on whether or not ctxt, Options, and ScratchDir are objects or data structures. If they are objects, then their internal structure should be hidden rather than exposed, and so knowledge of their innards is a clear violation of the Law of Demeter. On the other hand, if ctxt, Options, and ScratchDir are just data structures with no behavior, then they naturally expose their internal structure, and so Demeter does not apply.

The use of accessor functions confuses the issue. If the code had been written as follows, then we probably wouldn’t be asking about Demeter violations.

final String outputDir = ctxt.options.scratchDir.absolutePath;

So this is probably where your co-workers are coming from. I think the argument “we have to do this because LoD” is imprecise at best. The central issue isn’t LoD so much as whether the API consists of objects or data structures. It does seem like an unnecessary and error-prone change to push through when there are more pressing things to do.

More Related Contents:

  1. Singletons vs. Application Context in Android?
  2. Why is volatile used in double checked locking
  3. What are static factory methods?
  4. What components are MVC in JSF MVC framework?
  5. Real World Example of the Strategy Pattern
  6. Design Patterns: Factory vs Factory method vs Abstract Factory
  7. MVC pattern on Android
  8. Abstract class vs Interface in Java
  9. Long list of if statements in Java
  10. Converting many ‘if else’ statements to a cleaner approach [duplicate]
  11. Double Checked Locking in Singleton
  12. When should we use Observer and Observable?
  13. Marker Interfaces in Java?
  14. Why do we need immutable class?
  15. Is there a Java equivalent or methodology for the typedef keyword in C++?
  16. why business logic should be moved out of JSP?
  17. Singleton Design Pattern: Pitfalls [closed]
  18. Why implementing a Singleton pattern in Java code is (sometimes) considered an anti-pattern in Java world?
  19. Replacing if else statement with pattern
  20. Java – Learning MVC [closed]
  21. Java JSON serialization – best practice
  22. Favor composition over inheritance [duplicate]
  23. Using Command Design pattern
  24. How to implement a FSM – Finite State Machine in Java
  25. Other Ways of Singleton in Java [duplicate]
  26. Open Session In View Pattern
  27. Builder Pattern and Inheritance
  28. Is there a recommended way to use the Observer pattern in MVP using GWT?
  29. Why does every object in Java implicitly extend java.lang.Object class?
  30. How to change method behaviour through reflection?

Leave a Comment