Hello Arunbear,

Thank-you and ++ for an excellent post! I think it would make a useful tutorial.

It might be a good idea to add a little information up-front on why encapsulation is a Good Thing. First, you could note that:

encapsulation is one of the four fundamentals of OOP
— Wikipedia, “Encapsulation”

(The others being abstraction, inheritance, and polymorphism.) Then, you could use the following quote from Scott Meyers (one of the gurus of C++) to show why encapsulation is valuable:

Encapsulation is a means, not an end. There’s nothing inherently desirable about encapsulation. Encapsulation is useful only because it yields other things in our software that we care about. In particular, it yields flexibility and robustness.
...
This is the real problem with poor encapsulation: it precludes future implementation changes. Unencapsulated software is inflexible, and as a result, it’s not very robust. When the world changes, the software is unable to gracefully change with it.
— “How Non-Member Functions Improve Encapsulation,” Dr. Dobb’s Journal (1^st February, 2000)

That’s an article I would recommend to anyone interested in OO.

Finally, you should perhaps point out that OOP is a programming paradigm, or methodology, and as such should not be confused with “OO language features” (such as bless) which are provided to facilitate implementation of the paradigm. It is possible to write an OO programme in straight C (I’ve seen it done very competently), and all-too-easy to write non-OO programmes in “pure OO” languages such as Java. Emphasising this distinction should help to forestall objections from those who find encapsulation to be “restrictive and prohibitive” — by pointing out that they are entirely free to use bless, etc., in any way they choose; but that when they choose to do so in a way which eschews encapsulation, the code they produce is, by definition, not OO.

Hope that helps,