David,

> How many places the code needs to be changed depends on what techniques
> were used to develop the code in the first place.
>
> If a User Defined Function is copied into different files for several
> clients and some of them have customizations then all those files need
> to be changed.

The same may true if the classes were copied to each project and you find an error in the root class.


> If the User Defined Function is in a library and the code is implemented
> as one huge CASE statement controlling it's variable behavior then it only
> needs to be changed in one place. The major problem with this is that the
> module becomes more and more fragile and error prone as time goes on.

I personally believe the readability, fragility, and maintainability of a module or class is much more dependent on the developer's ability to organize his thoughts than on whether or not OOP techniques were used.

We all have seen 50+ Case funtions that were easy to maintain and 10-line program that were next to impossible to decipher. We all have seen the Subclass from Hell that has 100+ custom properties and methods and that is 7 levels removed from the root class.


> It's even possible to have a poor O-O implementation that would
> necessitate changing code in several places.
>
> I am a strong advocate of eliminating duplicated code as much as
> absolutely possible. Sometimes O-O is the best way to achieve this, other
> times a simple User Defined Function is the best way.

We are advocating the same thing. I had a problem with your earlier post because I thought you were one of those OOP is king, everything else is crap evangilist that I encounter too often on this forum. I'm glad to see I was proven wrong!

Daniel