The Law of Demeter

The Law of Demeter is something I wish I had learnt early on in my development career. Why isn't at least a whole lecture on this in university? Perhaps there is now.

The best thing about the Law of Demeter is it is short and succinct making it easy to remember:

More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:
O itself
M's parameters
any objects created/instantiated within M
O's direct component objects

There are just some straight-forward rules for developers to follow to keep their software free of unnecessary dependencies and loosely coupled. People often talk about the need to be loosely coupled and to cut down on dependencies, but I just love how the Law of Demeter just lays it down on how exactly that should be done.

Code that doesn't follow the Law of Demeter can quickly bring the development of that software to a slow crawl. The worst situation you can get into when developing software is when everyone is too scared to touch it. Once you are there, the software has hit its peak. Following Law of Demeter (along with unit testing! get into it!) will keep that software moving along like a smooth well-oiled engine or an agile and nimble ninja. And we all love ninjas.

I first learnt this only about 6 months ago in The Pragmatic Programmer: From Journeyman to Master which is a fantastic book all software developers should read. I can't recommend it highly enough.

I guess it was the sort of practice I already knew and was following where possible, but it was good to see it so clearly presented. Great for passing that knowledge onto others as I sometimes struggle to articulate such things.