When [responsibilities aren't well defined for classes], it's a clear symptom of a common issue known as the "Law of Demeter" breakage. In case the name doesn't ring any bells, the "Law of Demeter" (http://en.wikipedia.org/wiki/Law_of_Demeter) - or the Principle of Least Knowledge - is a paradigm that allows to create loosely-coupled classes, based on a simple concept: each class should be designed to work properly using only the dependencies that it really needs.

He talks about how violation of this law (whether you knew you were or not) can lead to some bad coupling practices. He includes a few classes under a SampleApp that handles the interface between a database and the domain model. The violation of the law comes in when the database and service layers are introduced - a fetch the code does to get an adapter from the service locator rather than directly from the database functionality as it should.

There's code for everything included in the post

Oh how we love acronyms. We've discussed a lot about writing a class, but we haven't talked about writing classes yet. How do you know if your solution is right? It is not enough to have a working program. SOLID is a set of principles that define severable measurable properties your architecture should have at least, in order to be dubbed right.

He goes through each of the principles (single responsibility principle, Liskov substitution principle, etc) and gives a summary statement, a definition and code illustrating it in use. The examples aren't all based on the same code as implementing all of these principles at once as been found to be difficult. He also includes another principle to keep in mind - the "Law of Demeter" dealing with calling scope of properties and methods.