OO Design Principles Compilation

Notice the number of shoulds. A list of what you should do is like training wheels: useful for beginners but not as much for the advanced.

Instead of thinking in shoulds I like to think in terms of causes and effects. If you don't follow the law of demeter then these will be the effects. Then the programmer realizes they have a choice: even though the law of demeter usually brings about desirable consequences, maybe in a particular situation the effects of not following the law of demeter bring about the better set of consequences.

Thinking in terms of causes and effects also loosens potential dogma.

I prefer to think of these as rules of thumb rather than principles. I agree with the spirit of pretty much all of them, but to me, "principle" sounds like one of those rules you're never supposed to break. There are often trade-offs to following these sorts of rules, and sometimes the cost is too high or the process too idealised for real world projects.

This list is very useful. It's 2011 now and you have no idea how many people don't know more than half of the list.

following the same topic... http://www.barbarianmeetscoding.com/blog/2011/2/23/best-prac...

There's only one rule to OOP: All instance variables should be private.