The LA Fox Developer Newsletter

August 1999

Framework (Con't from page 4)

should meet those requirements and nothing more. All function ality outside the frameworks boundaries should be handled by the developer. When a framework crosses the boundary it becomes oveily complex and it is likely that the developer trying to use it will need to code around the framework’s behaviors in order to accomplish their goals.

A framework does NOT provide the functionality for the application, it provides the skeleton upon which that functionality is budt. The application functionality is the responsibility of the developer who uses the framework and the framework should not get in their way.

If a framework developer wants to provide further specialized classes for the application developer to use, these should be supplied in separate class libraries as subclasses of the framework classes. This will allow any developer to choose to use or not use these specialized classes. It also makes a clear distinction between the framework and the developer’s toolkit. Coincidentally, this also gives the developer clear examples of how to subclass the framework classes to get the specialized behavior that the developer might want thus making it easier for the developer to learn the framework.

Expandability

It should be easy for the developer to expand the framework by either adding new classes or by subclassing the existing ciasses. A framework whose behavior is not easily modified restricts the developer rather than empowering them.

The only sure way that a framework can provide expandability is by including it in the design. Expandability is not an afterthought.

Hooks, hooks, and more hooks

One way to provide for expandability is by providing the developer with methods in which they can write code that will affect the behavior of the framework. For example, if the framework has a form that will save the users edit in a method named SaveWork, then adding a BeforeSaveWork and AfterSaveWork method which are called by the SaveWork can provide the developer with places to write code before the users edit is saved and after the save has been completed. Further, if the SaveWork method respects the value returned from the BeforeSaveWork method the developer can actually decide to stop the saving without ever looking at the code in the framework class, they can simply return .F. from the BeforeSaveWork method.

These kinds of hooks can, and should, be provided wherever they make sense.

Abstract Design

Below is an example of an abstract design for a framework.

Designing Class Hierarchy

The design of class hierarchies is beyond the scope of this paper, but some discussion is necessary. In order for a framework to be simple to use and to provide for flexibility in the use of the framework the class definitions should meet at least certain basic design goals. Every branch in the class tree should start with a single abstract class definition that I will call the root class. This root class should have no code in it at all, but rather should be the class where we add the properties and methods that the subclasses will use to provide the code. This approach provides the structure for having a clear and consistent public interface to the classes in our class libraries.

The class design must provide a clear boundary representing the end of the framework ano the beginning of the application. The diagram below shows an example using a set of form classes, the italic text indicates the classes that are abstract and will not be used to create objects.

(Ed.Note: Jim Booth, Microsoft MVP, will be one of the featured speakers at the 3rd Annual Southern California Visual FoxPro Conference. Send mail to jbooth@jamesbooth.com with questions or comments about this article.]

Page 5