This is an answer to the question you posted in the comment on @AlfredoCasado's answer. It's only about the encapsulation aspect of your question.
[tl;dr]: The important thing about encapsulation is getting the functionality in methods/properties, not restricting access to the data.
The Wikipedia Article about encapsulation mentions these two definitions:
- A language mechanism for restricting access to some of the object's components.
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
Many believe the first one (data hiding and access control) is the most important, and the article alludes to this. Note Robert Harvey's comment about rules: this is one you can be less guilty about breaking. Data Hiding is about 15-20% of the benefit. Using a property to wrap a member, by the way, is not even data hiding (unless it's a value type you're making read-only, or, returning a clone of a reference type or an immutable type; but often those are OOAD hints that you should be returning a value from a method).
Most of the benefit of Encapsulation comes from the 2nd item: bundling data. I would also add, organizing functionality in methods of an object (which also hides implementation, but that's not the point). This is 80-85% of the benefit of encapsulation.
Thus instead of an object's consumer having to worry about the details, you can do (and see) in a few lines of code, using terms from your ubiquitous language, that you've carried over into your method names, exactly what you want.
Then no matter how smart you are, your brain uses less horsepower, and you can do more. That's the 'magic' of OO right there. Data hiding isn't.
Another note about data hiding: It's just a hint to the programmers of the objects you made (50-80% of the time this is you). Devs can (and I see it all the time) check out your class and make private stuff public. Even if you're writing libraries for sale (and who does that?) they can use reflection to hack it. We've done it at my shop and saved tons of money! Who cares if the next version breaks because the implementation was private? We have control over which version we use!!
Bottom line you have to know or notice either way. If you don't know why it's private you won't take the hint. If you do, it won't matter. Yes, data hiding pushes devs in the right direction, and encourages good modelling practices. Here's the Elephant in the room: Encourage all you want. A person who doesn't know OOAD won't learn from encouragement. Better to spend the time teaching them.
Wow, that was long.
edit (See comment by @DavidKennedy85) I completely agree ... however, organizing the implementation into methods of an object (which I bet you do) provides that functionality as well - an accomplishes the lion's share of the benefits of encapsulation. I am not implying the first aspect is worthless - this is just what is taught so much (bulk of article reflects that). The quote you mention brings up an important point - limiting the size of the interface surface to a cleverly-succinct small subset. (limit interdependencies). Another way to improve objects is to limit that state the object retains - meaning there will be fewer fields to make private. I am sure we agree on this things - I am just pointing out the obvious that for a dev to design her objects right, she has to start by first knowing how, then doing the design, and the private fields and methods will automatically become obvious without her having had to think about their accessibility; however focusing first on the fact that some things should have limited access isn't nearly as useful as the mountain of other 'artwork' that is involved in a proper design, and if proper design is done, what's public and private in the end won't be the thing that matters.
A crappy design can expose itself in lots of publics - but that could be a good design. You can also have a crappy design with very few publics.
Now I'm just ranting - but I have a right to with every other programmer that came out of uni being told that it would be as easy as data hiding and a couple other concepts that sound good but are too basic to be helpful (like 'is-a/has-a'). It's not, it's much harder, and I was not taught the important things!