Ownership of Classes
In the above sample, you might question why the XYZ Company chose to create a new subclass based on dbForm. Why didn’t they just modify the dbForm class? After all, the source is provided. The answer to this question is that they do not "own" the classes.
You do not want to change classes that you do not own. The term ownership is not used in a legal sense; it refers to the fact that you are not responsible for the class. If someone else is in charge of writing and maintaining class code, you do not own it. As long as modifications to superclasses are documented, there will be minimal problems in making whatever changes would be needed in the subclasses. The XYZ Company will then have minimal problems making whatever modifications they need to make in their classes.
Let's use some examples. In the next release, Data Access Corporation makes major internal changes in their dbGrid class. The new class’s message interface is unchanged, but the speed of the grid is stunningly faster. No changes will be required in the XYZ Company's dbGrid_xyz class to support this. If XYZ Company had made their changes directly to the DataFlex dbGrid class, they would both have to spend significant time updating this. They would probably have to read the new code and add their enhancements all over again.
If you create your own subclasses based on the DataFlex classes (and you are encouraged to do this), you should plan on extending the subclass tree down one more level and placing all of your changes at that level. This will put you in the strongest possible upgrade path.