Question

Does Information Hiding mean I should minimize the number of properties my classes have? Is that right? Do you tend to make your classes private fields with methods?

Answer 1

Ever strike up a conversation by asking ‘How are you?’, only to be met with a litany of their troubles and triumphs, pet peeves and uninteresting interests, feelings of insecurity and maybe an in-depth review of the breakfast muffins…

…that’s not information hiding. Most of us don’t do that. Kids do, at least until they first meet someone who uses all the irrelevant information they’re sharing to hurt or humiliate them in some way… then, they learn to be secretive and paranoid, one more step on the road to adulthood.

Most of us also learn to do the same sort of thing with the code we write, exposing just enough to get along with other code, but not so much as to allow it to become dependent on our implementation. This is somewhat more nuanced than simply not exposing internal data – merely placing accessor methods or property getters/setters between internal data and the cold outside world is no more information hiding than launching into a conversation about ‘this friend of mine’ and ‘his’ herpes problem…

You arrive at the heart of the question when you start to differentiate between interface and implementation. When you expose properties because they match the view of the world your client code expects, rather than because they provide a convenient way for them to manipulate your implementation. It’s rarely a clean divide, even when developing top-down, and contrived examples can easily do more harm than good: going out of your way to obfuscate an implementation detail that happens to be a perfectly good interface is down-right harmful.