>> use-cases and real world applications are far more useful than design-patterns per se.

Baloney :-)

I can't find a single useful URL or book that conveys a real-world application or a set of use cases that can help anybody design any application whatsoever.

How this dearth (as in zero) level of resources can possibly be "far more useful than design patterns", per se or not per se, is completely beyond my impression or even imagination of reality.

Design Patterns are about abstraction and language. But you knew that.

**--** Steve



>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...