Tom..

IMO, the OOP issue has been over-"academized" (in quotes because I don't think it is a real word...). The area of design-patterns is one such area. IMO, use-cases and real world applications are far more useful than design-patterns per se.

I think there are some definite theorhetical under-pinnings the people have to understand (class, object, inheritence, encapsulation, polymorphism, property, method, abstraction, etc...). If one understands these concepts, it then becomes a matter of putting it all together. This of course is where people get into trouble...

The point of having to debug one's own code in the future is a good one. I reject the notion that OOP makes for inherently more maintainable code. I do agree that OOP has the POTENTIAL for more maintainable code. Then again, so does the procedural platform. I have seen theorhetically good OOP code that was not maintainable. This is particulary true with solutions that have been over-engineered. And I have seen bad procedural code that could be maintained.

Which is better.. bad code with comments or great code w/o comments??? Something to ponder...

Ultimately, the KISS principle applies...