Object Oriented Programming (OOP) brings in the concept of looking at the real world as a set of objects, that helps in modelling software systems as close as possible to the real world – the ultimate motive of automation. The automation involves designing not only the objects, but also the interaction between them. There are some efforts for betterment of guidelines to effectively apply OOP to designing real world systems, business systems. One of the notable ones is the Law Of Demeter.
Law Of Demeter
The Law of Demeter (LoD), more accurately Law of Demeter for Functions/Methods (LoD-F), is a style for OOP that uses the principle of least knowledge of other objects. The main aim of LoD is to control information overload by defining rules for interaction between objects – Only talk to immediate friends.
A more general formulation of the Law of Demeter is: Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
When applied to OOP, the unit is a method, and the closely related units are methods of
- self
- arguments passed to the method
- immediate part classes of self
Whenever a method invokes methods of other objects, it assumes a structure about its class. More so, when it uses the return objects of those methods and invokes methods on them. A change in the structure of the objects can cause a change in this method. LoD tries to define a scope for the objects whose structure we “can” know, which are mentioned above. Here is an example, the following code violates LoD:
alpha = beta.getAlpha() gamma = alpha.getGamma()
Assuming that beta was passed as an argument, we “can” know structure of class of object beta. We hae also invoked a method on object alpha, exposing its structure to us. If alpha’s class structure changes, our code here might have to change. Instead of this, we can have:
gamma = beta.getGamma()
Since beta has returned the object alpha, it already knows alpha’s structure and can invoke its methods. Here beta is a closely related unit whereas alpha is a stranger.
David Block explains Law of Demeter nicely to show a practical application, and how LoD helps in achieving design closer to the real world.
Abstraction
At an abstraction, the LoD looks at the start and end points, it refrains from specifying the intermediate steps required. The intermediate steps are subpart of the object whose method has been invoked. In addition to enhancing the encapsulation, it identifies and separates responsibilities and duties of individual objects involved. The separation of duties results in loose coupling of objects, freeing them to change independent of each other.
Aspect Oriented Programming
The LoD also leads us to Aspect Oriented Programming, which deals with separation of concerns.
Rumbaugh summarizes the Law of Demeter as: A method should have limited knowledge of an object model. This view leads to aspect-oriented programming: we pull out the method and transitively all its auxiliary methods into a separate aspect. This works best if the separate aspect has limited knowledge about the object model.
Related links:
- Law of Demeter
- A general forumation of Law of Demeter
- Introducing Demeter and its Laws
- What Is Interface?
- What Makes An Effective Interface?
Back to Design Principles.
Technorati tags: law of demeter, lod, object oriented, encapsulation, separation of duties, design, programming, aspect oriented programming
Copyright Abhijit Nadgouda.
Abhijit Nadgouda @ iface 
Leave a comment