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 understand. 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 framework. A framework has clear and succinct responsibilities i

(Con’t, page 5)

Page 4