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 applica-

tion, 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 after-

thought.

Hooks, hooks, and more hooks

One way to provide for expandability is by providing the devel-

oper 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 frame-

work 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 frame-

work 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 consis-

tent 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