Abhi: I’m going to disagree with your last paragraph, but only on a very nit-picky kind of way 🙂
I believe that it is easy to confuse hiding data with providing a clean interface. The idea of a functional contract between components does not *require* any kind of restriction, it simply requires that the interface through which the function is provided does not change.
This contract may be provided in the form of documentation, naming conventions, even a simple phone call to describe that single method used as an entry point to a library. It can even go so far to say that a contract is made by simply keeping the client code ignorant of internal attribute names, so that they won’t use them. If you hack the library to find and use the internal symbols, you should not be surprised when the library starts acting weird, right?
The public and private keywords are specific to languages like C++ and java, and the only reason that I could see a use for them is if the person writing client code was actually reading the headers that defined the class. Including type headers (which is only a convention!) is a language-specific thing, and do not *facilitate* this contract, they only provide a semantic (compile-time!
) helping hand for a language’s *implementation* to remind a programmer that they are breaking the contract.
If I were teaching an OO basics class, I would not teach that “encapsulation” is necessary for object-orientedness. Instead I would focus on the idae of clean *abstraction*, which is the separation of components to ensure that one can be changed without affecting the other. This can be just easily be achieved by providing a wrapper class, or naming methods using an underscore convention like “_handsOffThisWillBreakTheContract”, or simply keeping the names of the “private” methods and attributes out of the docs, whether those docs are defined as the html user docs or the class header file itself.
I will say that I am tired of hearing that encapsulation has anything to do with object oriented programming. Shoot, even abstraction is only necessary in *some* cases, and it can just as easily be achieved in a structured language like C, and so also has nothing to do with object oriented programming.
The “object oriented” concept provides nothing more than a thin semantic helping hand, in the form of a real-world representation instances of stageful types that provide a function. Everything else is nothing more than language implementation.