Good point with the Salary field. That could be considered a part of the public interface of the Empoyee class. And querying the Salary or Name of an Employee in order to display them or something, that would be okay. But as soon as you start comparing the Salary with something else that was taken out from inside the object, you're losing cohesion.

After I read about this the first time, I thought I'd try to follow the sentiment of the principle, and that has resulted in better designed OO code, without me doing much designing. It just falls out of the principle.

The wiki page really states the principle so much more succinct than what I wrote above: "It is okay to use accessors to get the state of an object, as long as you don't use the result to make decisions outside the object."

Something I've noticed is that sometimgs it's vague where a piece of logic belongs: which class should implement the method, taking a property from another object as a parameter.

For example: "is the Employee's Salary above average in her Department?" Should that go in the Employee class, or the Department class? It depends on the rest of the design.

/J