>Why does VFP override the methods by default? In a team environment, this can cause many problems. Eventually everyone will execute our macro to "DODEFAULT()" when adding code to methods of our classes without having to think about it.
>
>As one adds code to a class in Delphi, it automatically adds a INHERIT keyword. The developer must make a conscious effort to override the parent class code. Doesn't this make more sense? If the purpose of developing classes is for code re-use and inheritance, then VFP should not override by default. This would also be useful when using third party classes...
>
>Is this reasonable, or is there a method to this madness?

Hi Jack,

I'd take issue with the title of this thread. Inheritance isn't a prime reason for OOP. OOP, like structure programming before it, was developed to simplify development and, more importantly, application maintenance. How these two methodologies approach the problem is almost identical from a theorhetical point of view.

Both are intended to promote modules (read programs or objects) that exhibit low or loose coupling and are highly cohesive. Coupling refers to the dependence of the object/program on external conditions or values. Cohesion refers to what it does. Ideally an object or program module should be as independent of externals as possible and do one thing.

Both aim to solve maintenance and development problems by developing re-usable code or objects that only have to be developed and debugged once. In short, aim to eliminate the "re-invent the wheel" syndrome.

As objects/programs become more complex they become less re-usable. Individual parts may and should be re-used over and over again, but the resultant whole probably will not be.

The main problem that can result, however, was discussed in Drew Speedie's excellent article "The Dangers of Composite Classes" which appears in FoxPro Advisor some time ago. In it, he discussed how mis-using inheritance can create problems in applications that are caused by overriding the default behavior of objects within several layers of inheritance.

I think that sometimes, in the name of polymorphism, we encounter a problem which is extremely similar to one we have been, and alter an object's behavior without clearly thinking the consequences through. I can this the "Square peg in the round hole" approach. I kind of, sort of, but not quite, have something to do the job, so I subclass it, use the default properties/moethds in some cases, and override others. Later I go in, make a change to the parent, only to find that I've completely broken the child. This, IMHO, runs completely contrary to the underlying purpose of OOP.

In an instance like the above, what's really needed is to re-use those objects that apply, and develop new ones for those that don't after a thorough analysis of the problem.

I don't know how much of the above applies to your situation, however, I hope it provides some food for thought.