Design Pattern Principles for ActionScript 3.0: The Least Knowledge Principle

For those of you who have developed applications where a reference drills down through a series of movie clips, the Least Knowledge Principle may seem a bit harsh. It is very easy and even shows a semblance of foresight and organization to arrange operations in a movie clip set to have each movie clip do one thing in a complex object. To get something working, though, you do not want to rely on drill-down references that visit each of the many movie clips. Statements such as,

myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…

break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.

One Dot Over the Line

First of all, few principles have as many names as the Least Knowledge Principle. Here they are—as an aid to remember what the point is and resource to find out more.

1. Law of Demeter: This term emanated from Northeastern University’s Demeter project. The name Demeter is from the goddess of agriculture which (to me) is more confusing than helpful. The Law of Demeter states:
   

   A method “M” of an object “O” should invoke only the methods of the following kinds of objects:

   • itself
   • its parameters
   • any objects it creates/instantiates
   • its direct component objects

   The Law of Demeter is the most specific as to what you should invoke as far as methods are concerned. Remember these four objects—the object itself, its parameters, instantiated objects and direct component objects.

2. One Dot Rule: Of all of the names for the Least Knowledge principle, the One Dot Rule is the most helpful in terms of a simple formula to remember. However, the advice to “use only one dot” is often the subject of heated (is there any other type?) debate among programmers. Generally, they miss the point, which is that any change in between the dots can be catastrophic when making changes. For example a statement like,
   object1.object2.object3.methodA();
   can have dire consequences if one changes either object2 or object 3.
3. French Mistress Rule (entre nous): This one doesn’t count since I coined it for our more romantic readers. It’s also known as the Secret Lover Principle, with the main idea being that if you carry on une affaire du coeur you had better keep it between you and your amoureux. As you can imagine, this helps remind you that you don’t want to provide anyone with more information than they can handle or need. What usually happens in these situations is that you just communicate with your closest friends—just as you should in programming.

Some will conclude that this principle sounds a lot like delegation and why bother with a redundant principle? Well, in a nutshell, it is a lot like delegation—some might even say it’s just another name for delegation. I cannot argue with that point, because delegation is definitely implied in this Least Knowledge Principle. However, the principle is very instructive in that it points out a very specific way to think about coding and building programs. So while it’s a lot like delegation, it focuses on a specific aspect of delegation and organizing a program.

Least Knowledge in Design Patterns

Given all of those different angles on the Least Knowledge Principle, you may wonder what all of this has to do with design patterns. Remembering that the purpose of design patterns is to generate reusable code and programs that are easy to change, the principle keeps us from tangling up our references with too much information that may change in different parts.

Probably the best example of the Least Knowledge Principle at work is the Façade Design Pattern. (In fact, in the Façade post, we noted that the Least Knowledge Principle was at work.) In the Façade, instead of making requests through the myriad of classes in another system, all requests are made through the Façade. The requester (Client in this case) just communicates with the Façade and doesn’t know or need to know the details of the other classes. Thus, it can communicate just with its close friends and not become entangled in all of the subsystem classes.

Other Least Knowledge examples can be found in design patterns that use wrappers. In the Proxy pattern, the Client does not communicate with the concrete class, but instead makes requests through a proxy class. Likewise, the Decorator and the Adapter patterns (Chapters 4 and 5 in our book) use wrappers to keep the structure loose and adaptable. In the Decorator, the requests are made through the decorators (wrappers) to the concrete classes that reference the concrete classes as parameters in the instantiation of a decorator. Likewise in the Adapter, requests are through a target interface instance of an adapter object to any adaptee component. The client has no idea of the details and does not need them.

Into the Lunch Bucket
The Least Knowledge principle is easy to remember by at least one of the names it’s called. Using the “use only one dot” rule, you’ll find yourself better off in terms of what might break. Of course we have to live with exceptions, such as the Shape.graphics.method() statements built into ActionScript 3.0 (for the time being at least), but you really need to rethink setting up movie clips within movie clips within movie clips, ad nauseam.

Those who prefer to use the term Law of Demeter seem to have the best horror stories. In one such story I came across, the Law of Demeter was broken in some software that was being used for the Mars pathfinder, and you can imagine the problems that would have caused—your programmer isn’t going to make a house call on that one!

We have found, however, that breaking the LoD (Law of Demeter) is very expensive! On Mars Pathfinder, the integration costs of the law breaking parts of the system were at least an order of magnitude higher, and we had to pay that cost on every integration cycle — not just once! We should have paid the cost once by implementing a more sophisticated protocol that did obey the LoD. (Email from David.E.Smyth at NASA’s JPL.)

Also, Miško Hevery’s article on breaking the Law of Demeter is quite good. He uses the analogy of finding a needle in a haystack for the debugging process where the law has been violated. Now put that together with trying to fix a buggy program on the Mars pathfinder!

It’s easier for me to think of the principle in terms of only speaking to your immediate friends or keeping it entre nous. It works best for thinking in terms communicating in shorter links—sort of like a line of people holding hands and just talking to the person on the left or right. It’s not exactly that restrictive, but it helps me to keep the concept in my head. In an upcoming post on the Decorator design pattern on this blog, I hope to show how the Least Knowledge principle is applied in a wrapper application.

In the meantime, take this principle to work in your lunch bucket. If you call a method, remember to keep it close to the vest, and your objects need to know as little as possible about the internal structures of the methods they call outside of their own structure. You should never hear your objects mutter, that’s way more than I needed to know.

The Design Pattern Principles for ActionScript 3.0: The Least Knowledge Principle by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. ActionScript Facade Design Pattern: The Cat Herder
2. Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle
3. Design Pattern Principles for ActionScript 3.0: The Dependency Inversion Principle