The Law of Demeter (LoD) as it is commonly called, is really more precisely the “Law of Demeter for Methods”. It is a design-style rule for object-oriented programs, but can be applied to ‘pseudo object-orientated’ languages such as ColdFusion (with regard to the use of ColdFusion Components). In essence it is the “principle of least knowledge” regarding the object instances used within a method. The idea is to assume as little as possible about the structure and properties of instances and their sub-parts. Therefore, it is okay to request a service of an objects instance, but if I reach into that object to access another sub-object and request a service of that sub-object, I am making an assumption of the deeper structure of the original object. This results in tight coupling, which is a sign of a poorly structured application.
The Law of Demeter says that if I need to request a service of an objects sub-part, I should instead make the request of the object itself and let it propagate this request to all relevant sub-parts, therefore the object is responsible for knowing its internal make-up instead of the method that uses it.
Stated in plain English:
- You can play with yourself
- You can play with your own toys (but you can’t take them apart)
- You can play with toys that were given to you; and
- You can play with toys you’ve made yourself.
Stated more succinctly, the Law of Demeter for Functions says that:
- Your method can call other methods in its class directly
- Your method can call methods on its own fields directly (but not on the fields’ fields)
- When your method takes parameters, your method can call methods on those parameters directly; and
- When your method creates local objects, that method can call method on the local objects.
The basic idea is to avoid invoking methods of a member object that is returned by another method. When you do this, you make structural assumptions about the container object that may be likely to change. The container object may later need to be modified to contain a different number of the contained objects, or it may end up being changed to contain another object which contains the original component object. If the ‘returned’ object isn’t a sub-part of the object whose method was invoked, nor of some other object, then it typically is not a violation of LoD to invoke a method of the returned object (particularly if the object was created by the invoking method).Using the Law of Demeter (LoD) you instead ask the container to invoke a method on its elements and return the result. The details of how the container propagates the message to its elements are encapsulated by the containing object. This results in weak coupling and strong cohesion, the general goal of high readability and maintainability of an application. This is highly desirable when building a ‘modern’ ColdFusion application as it is all too easy getting trapped into the bad-old-days of “spaghetti code”.
A side-effect of this is that if you conform to LoD, while it may quite increase the maintainability and ‘adaptiveness’ of your application, you also end up having to write lots of little wrapper methods to propagate methods calls to its components, which can add development time overhead.