Information hiding is one of the very essential principles of object orientation. If you dont know it well, I suggest you take a look at it on the Web, e-g at UncleBob.
But information hiding is much more than just putting data private through accessors to protect them, it is especially a great tool to manage complexity.
Everytime you put together data that go together, you hide these data behind the object that contains them, and as a result, instead of dealing with 2 or 5 pieces of data, you can only deal with one, so you win the complexity battle. If you simply do that several time, you can end up managing hundreds of data with little effort.
This very little principle can really save your life. One extremely common application is the Quantity pattern (Fowler), as value and unit always go together (or they should), they are ideally grouped together as a quantity object, like Money, Percent, Period… Just putting together a value and its unit already yields surprisingly high return, (and of course you become unit-safe).
Let’s illustrate this post with our current project; we replaced some terrible 25-fields legacy data objects by objects with 2 to 5 fields, themselves again made of 2 to 5 fields objects, and so forth. The actual object structure is a tree, but most of the time we only care of one level at a time: we always have a simple object, it is easy to deal with it.
This way, we get many benefits: each object is simple, easy to create; each such object that groups together some fields has a name, it is a unit of concept, we can talk about it, and this very point is really valuable; we can very often reuse the objects as-is (the same instance) from different pieces of the application, no more need to copy fields to fields; they can often be made immutable; and of course we can unit test such small objects (yes we can have bugs even in simple things).
And if you claim that having several such objects instead of just dealing with “flat” primitive fields is costly, then you are victim of the Primitive Obsession syndrom!