Saturday, August 14, 2004

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.

3 comments:

Siddhi said...

You're absolutely correct. I've had the same experience in teaching OOP to others. It takes a different midset altogether to think with objects. Its really hard to teach this, you just have to hope that they get that AHA moment when everything magically clicks. Usually, this comes with a bit of experience, so its not something that can be taught in a couple of weeks.

Sachin said...

Hey K,

I agree, a lot of programming experience really helps and that was one of my points in the entry. Over time coding in C, we all start to follow some patterns to make life easier and when someone describes OOP to you the patterns seem to make sense. Explaining OOP to a guy who has dealt with large C programs is probably easier than people who have written lots of short (length wise and shelf-life wise) programs. The large program guys have felt the pain of not having abstractions, not being able to make non-rippling changes, etc.

Anonymous said...

I am skeptical of OOP alleged benefits except for a few narrow uses. I want to be shown realistic change scenarios and how OOP simplifies the impact of changes on code. So far OO proponents tend to supply an unrealistic mix change scenarios in my opinion. They only show scenarios that favor OO, but not those that bust polymorphic taxonomies, for example. I think they are blinded by OO teaching that emphasizes a limited set of change patterns. (see oop.ismad.com)