Users like to change things, right? Suppose, using our light example, the user changed the base definition of a light switch. In our example, a light switch only has one property (called status) and one method (called Lightswitch). Suppose the company redefined the base light switch (class LIGHT) to have an additional feature. Now, when the user turns the light off or on, the system will tell them what they have done.
In order to accomplish this, all we need to do is modify the Class definition of the light as follows:
DEFINE CLASS light AS custom status = "OFF" PROCEDURE LightSwitch IF this.status = "OFF" this.status = "ON" ELSE this.status = "OFF" ENDIF WAIT WINDOW "Light is now " + this.status RETURN ENDDEFINE
From this point on, all object instantiated from the class LIGHT will get the changed method. In effect, we have changed the behavior of every object based on this class by adding one line of code to the class definition.
But wait, there's more. Not only have we modified all the objects based on class LIGHT, we have also modified every object based on subclasses of light (e.g. Dimmer). This makes for a powerful way of developing reusable code. The flip side to this is if you break a class, you may also break all the subclasses (regardless of which application you have used it in) based on it. If you have used the class in a production application, you'll need to be very careful with this.