The LA Fox Developer Newsletter

August 1999

Framework (Con't from page 3)

Frameworks are comprised of many parts and these parts have

requirements that are placed on the other parts of the framework

and on the components of the application. These requirements

are called contracts.

When you select, or build, a framework there will be a method

prescribed for building your forms and the other parts of your

application in order to allow the framework to function correctly.

For example, the framework may require that your forms are

built as classes in a visual class library rather than as forms in

the form designer. Th:s may or may not be a problem for you.

Perhaps you prefer to use the visual dataenvironment designer

in the visual form designer, well if your framework requires forms

as classes then the visual dataenvironment designer is not an

option for you.

If you make heavy use of pageframes or grids in your interface

then you should be sure that your framework will provide good

support for these containers.

What Kind Of User Interface Do You Use?

User interfaces come in all sizes and shapes, mostly bad. Let’s

put that point to the side, this paper is about frameworks and

not user interfaces.

Your applications may present themselves to your users in one

of a variety of ways. There are process centric, data centric, and

god! centrie approaches to ths presentation. Process centric

applications focus the user on the processes that are done like

creating invoices, or applying cash receipts. Data centric

applications orient the user to the data they work with, these

types of applications ask the user to specify the file they are

interested in and then let the user manipulate or edit the records

in the chosen file. Finally, goal centric applications focuses the

user on their goals and presents activities that are goal directed.

Your framework will very likely be in your way if it is data centric

while you are building a goal centric application.

Determining the Scope

In observing a number of frameworks, both commercial and

custom built, the single most common problem I have seen is

that the framework goes too far. When a framework tries to be

more than the skeleton for your work it gets in your way. A

framework is NOT an application wizard!

Imagine you just bought a new car and you are ready to drive it

off the car lot. You get in, put the key in, start the car and press

on the gas. As you leave the lot you turn the wheel to the right,

but the car goes to the left. You stop and go back to the

salesman and ask, "Why does the car go left when I turn right”?

He says, oh that is a feature of this car, you see it sensed there

was a lot of traffic on the right so it went left for you instead. Not

a very good car!

Well if every time you wanted to present your user with a certain

set of options you first had to remove all of the options that the

framework put in for you, you would soon become just as

irritated with the framework.

You need to determine for what the framework is responsible

and for what the developer is responsible. Don’t use or build a

framework that makes the developer work harder to get the

result they want.

If you do build your own framework and you want to provide

additional functionality beyond the framework’s responsibility,

then build a developer’s toolkit as an addition to the framework.

That way the developer can decide to use your toolkit or not as

they choose and they are not bound by your style or approach.

Qualities of a Good Framework

Simplicity

The overall structure of the framework must be easy to under-

stand. A well designed framework can be taught to a new

developer in a few days at most. Obviously, the details of all of

the methods and properties involved are not taught in a few

days, but the new developer should be able to understand how

the thing works very quickly and then fill in the details as they

use it.

This simplicity is achieved by giving the parts of the framework

clear and consistent interfaces. All objects of the same lineage

should have the same interface. For example if a local data form

has a method named PackTables, so should the remote data

form even though the method would have no purpose in this

case. Why’T Because by all forms having the same methods we

can interchange the controls in the forms without concern. If we

had a delete button that had code to delete a record and then

call the form’s PackTables method this button could be safely

used in both the local and remote data forms because both

form’s have a PackTables method. In the remote data form the

PackTables method safely does nothing, but there is no error

when the button calls it.

Clarity

The behavioral aspects of the framework must be encapsulated.

It should not be necessary for the developer to know any of the

details about how the framework does something in order for

them to use the framework. If the developer must understand

the actual code in the framework then there is a definite design

problem in that framework.

The public interface for the classes in the framework should be

as simple as possible. Since it is the public interface that the

developer will be working with it is important to keep it no more

complex than is necessary to achieve the desired functionality.

The developer should not have to sequentially call three or four

methods in the framework to accomplish a certain process.

Boundaries

The single most common problem with frameworks that I have

seen is the lack, or violation, of the boundaries of the frame-

work. A framework has clear and succinct responsibilities i

(Con’t, page 5)

Page 4