ColdFusion and the Law of Demeter

Nice article Kola, glad you brought it to attention.

Kola, good article. I am fully on board with what you are saying, and as I am learning more about OOP, I can see that doing it the *right* way often takes more work, which is why I think we see things like person.getAddress().getPostalCode() so much. But, like you said, there are trade offs to this kind of programming. I am sure you have much more experience with these trade offs and I was wondering if there are standard times in which you do NOT follow this law?

Meaning, the address thing seems like a place where the trade off is generally not worth the 'clean' code. Like, if someone had a billing and shipping address, it would seem crazy to have to many get/set functions for all the parts of the different addresses.

Where do *you* ignore this rule?

@dc: Thanks

@Ben: If I had a person component that uses composition and contains a number of internal components, adding additional methods to the person component to delegate for every single method of all the internal components would lead to a component with a bloated interface. Another exception would be when using a factory. A factory will return a component which you would then want to call methods on. Finally any where it makes the code difficult to follow/maintain would also cause me to stop and think twice. For example if you have a component and add a method to it which doesn't seem like it should be on that component e.g. car.getAddress() vs car.getOwner().getAddress().

I think that the fact that it is called the 'Law' of Demeter is slightly misleading in that it seems like it is something you should always apply when really it's something you should use your judgement to apply.