Teaching Object Oriented Programming

I have been training someone in Java over the last couple of weeks. This is my first serious experience teaching programming at a one-on-one level. Although, several times, I have been asked to give training or product demonstrations they were for an audience that had already bought into the concept and were simply looking for a human user manual. Not so here.

The person I am teaching knows C and can "think in C". He thinks of logic as a set of functions into which you pass data (mostly primitive types) which operate upon them and so on. I am trying to teach him Java and I am more interested in getting him thinking about objects, design, patterns, etc. I have, however, been having trouble showing him the benefits of OOP(Object Oriented Programming).

OOP has the following advantages:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

Concepts like encapsulation can be grasped quite quickly by anyone who has burnt his hands with global data. But consider abstraction - this is not a concept that can be explained to or understood easily by someone who hasn't had to maintain and change the same software over a period of several years. Why should a user be represented by a User object and not a String userName? Why should there be a factory pattern used? The answers to most of these problems go like ... "If your specifications change in the future to include this feature also then designing it this way...blah blah blah". It is quite hard for someone whose programs have so far had a shelf life of a few laboratory assignment days to appreciate change management and the power of well designed Object Oriented Software.

Compile time polymorphism (function overloading)'s advantages are quite obvious. Perhaps, runtime-polymorphism can also be understood without too much trouble. It is however, Abstraction that is the core of well-designed software. Too much or too little breaks design completely. So, explaining abstraction continues to remain a challenge.

Proficient C programmers have their own way of making abstractions in C because they realize the value of abstractions to the human mind. I am not criticizing the C language. It is amongst the most expressive of computer languages ever devised. However, writing programs in the OOP paradigm using C is not something that comes naturally nor do most C books train in that manner. "Thinking" the OOP way is hard because one has to start thinking of <object>.operation(<params>) versus operation(<params>) that one is used to and this becomes a reasonably sized challenge for some.

I think there is a link somewhere between the proficiency in C and the ability to appreciate an OOP language. Once one has written programs in C that stretch one's mental programming capabilities where the complexities tend to cause that mist which makes one feel that things have gone horribly wrong, one starts to change one's way of programming (even in C). Resulting in an appreciation of what advantages "C with classes"(C++, Java) brings.