There are programming principles and there are frameworks to help us stick to those principles. One of those frameworks is––Law of Demeter.
Coupling is the degree of interdependence that exists between software components. Tightly coupled components are harder to maintain, modify and enhance overtime. For this reason, it's good to write loosely coupled functions as much as we can through out the development of a software program.
Honour thy functions and thy classes and keep them high up the altar away from undeserving stragers
LoD or principle of least knowledge is a design guideline for software development with the notion that a function or similar object should assume as little as possible about the properties and behaviours of components it comes in contact with. It is a novel way of loosely coupling software artifacts to make evolution much easier. It tries to prevent you from reaching into an object to gain access to a third object's methods.
Breakdown
The law states that any method of an object should call only methods belonging to:
- itself
- any parameters that were passed into the method
- any objects it created
- any directly held component objects
class Demeter {
private:
A *a;
int func();
public:
//...
void example(B& b);
}
void Demeter::example(B& b) {
C c;
int f = func(); // itself
b.invert(); // any parameters that were passed in to the method
a = new A();
a->setActive(); // any objects it created
c.print(); // any directly held component objects
}
The Worth
Theoretically, it sounds good. But, does it really help in writing more maintanable and adaptable code. Short answer––Yes.
Since components are not very knoledgable of each other, you can easily make changes to one without affecting the other.
There have been studies that show C++ classes with large response sets are more prone to error than classes with smaller response sets.
a response set is defined to be the number of functions directly invoked by methods of the class
Downside
Using the law of demeter will make your code more adaptable and robust, but at a cost: as a "general contractor", your module must delegate and manage any all subcontractors directly, without involving clients of your module. This means that you will be writing a large number of wrapper methods that simply forward the request on to a delegate. These wrapper methods will impose both a runtime cost and a space overhead, which may be significant––even prohibitive––in some applications.
Top comments (0)