OOPS Proper: What's an obtainable goal for centralized code in Visual DataFlex?

*Click on image to enlarge please...

OOPS proper coding goal is "no code in objects except property settings", is this obtainable?

The Visual DataFlex Studio and Database Builder utilities are the tools we use to build applications, and the coding style used in actual practice varies from "artist" to "artist" as much as a painting style does.

While the true goal of object oriented style of programming is to truly centralize code, and to produce an application where all customization departure from the basic tools we use should reside in classes, not objects. Further to this, each class has property settings for given or endowed abilities which allow us to re-use the class as instantiated in an object in different settings with different results depending on need.

Here is an example of such "art" in the fact that a module of data entry is first programmed with object code for the desired result, tested.... and then the code is moved to the classes involved for centralization and standardization. Standardization is a fundimental concept where you desire the same behavior in all modules or a programmed variance of same behavior, all set in a central place.

Visual DataFlex allows the programming and testing of object code rather than specifying that all instantiated objects be pure classes.

The "art" to this simple example as illustrated can be taken to many varying ways of implementation. One of the true advantages of VDF is the concept of multiple-inheritance.

Here's the challenge that multiple-inheritance solves:

We have a property setting "Set Auto_Clear_DEO_State to False" and a function SAVEHEADER which really belong both to the cWSdbView and cWSdbModalDialog class as well as possibly a cWSdbTabPage.

Shall we type these into the three classes three times? I think not! Remember our rule of thumb where "when you type code twice, it's time to rethink your methodology", and here's a solution using a MIXIN class. The MIXIN class is "mixed into" a class layer in addition to the regular superclass inheritance. Here's how.

click on image to enlarge please