Principle of Least Knowledge
Saturday, February 2nd, 2008One very important (yet often overlooked) design guideline which I advocate is the Principle of least knowledge.
The Principle of Least knowledge, also known as The law of Demeter, or more precisely, the Law of Demeter for Functions/Methods (LoD-F) is a design principle which provides guidelines for designing a system with minimal dependencies. It is typically summarized as “Only talk to your immediate friends.”
What this means is a client should only have knowledge of an objects members, and not have access to properties and methods of other objects via the members. To put it in simple terms you should only have access to the members of the object, and nothing beyond that. Think if it like this: if you use more than 1 dot you are violating the principle.
Consider the following: We have three classes: ClassA, ClassB and ClassC. ClassA has an instance member of type ClassB. ClassB has an instance member of type ClassC. This can be designed in such a way which allows direct access all the way down the dependency chain to ClassC or beyond, as in the following example:
// ClassA defines a member of type ClassB and provides
// access to the instance
public class ClassA
{
private var b:ClassB;
public function getB() : ClassB
{
return b;
}
}
// ClassB defines a member of type ClassC and provides
// access to the instance
public class ClassB
{
private var c:ClassC = new ClassC();
public function getC() : ClassC
{
return c;
}
}
// ClassC could expose additional members and on and
// on creating more and more direct dependencies
public class ClassC
{
public someType:SomeType;
…
}
// client implementation
var a:ClassA = new ClassA();
var sometype:SomeType = a.getB().getC().someType;
The above example is quite common, however it violates The Principle of Least Knowledge as it creates multiple dependencies, thus reducing maintainability as should the internal structure of ClassA need to change so would all instances of ClassA.
Now keep in mind that in all software development there are trade-offs to some degree. Sometimes performance trumps maintainability or vice-versa, other times readability trumps both. A perfect example of where you would not want to use The Principle of Least Knowledge is in a Cairngorm ModelLocator implementation. The Cairngorm ModelLocator violates the Principle of least knowledge for good reason - it simply would not be practical to write wrapper methods for every object on the ModelLocator. This is the main drawback of the Principle of least Knowledge; the need to create wrapper methods for each object, which are more formally known as Demeter Transmogrifiers.
The goal of good software design is to minimize dependencies, and by carefully following the guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.
Home
Contact