Chapter 16: Interfacing with the End User
into the form's module or class itself. Much of the business logicsuch as database connections, algorithms that
managed data structures, events, file operations, I/O, network connections, error handling, and so onwere
programmed in functions and procedures in one single form file (or at least encapsulated into it).
This model sufficed in the years before objects, because most applications, especially the ones written by
Delphi and Visual Basic programmers, centered around a heavy user interface, comprising a bunch of heavy
forms, that squatted on a user's computer. That was acceptable for the era because nothing but the form itself
was able to use the functionality built into it. This is illustrated in Figure 16−1, showing a fat form interacting
with the user and doing most of the application processing itself.
Figure 16−1: The fat form's logic is hard to maintain, reuse, extend, and debug
At the same time, packing all that functionality and data into a single form, or a collection of forms, did little
good for application design, maintenance, reusability, quality assurance, and so much more that
object−orientation brought.
Sure, by version 6 of classic VB, we had some semblance of OOP and could delegate specialized operations
and functionality to VB 6 classes. But inheritance and native interfaces were lacking, and thus it was not as
easy to decouple UI logic from business or core logic like you can with Java.
As we have discussed in the past 15 chapters, you have all the power you need in a pure object−oriented
framework to delegate UI logicinteracting with the user, getting data from the user, presenting data and
information to the userto the form. Behind the scenes, objects are delegated the tasks of getting information
from the components on the forms, processing and computing that information, and returning it to the form so
that the form can present it to the user. This is illustrated (similarly to Figure 1−2) in Figure 16−2, where
objects are created behind the form, and the form sits in the middle as the intermediary between business logic
on the back end and the end user on the front end.
Figure 16−2: The light form and its objects are easier to maintain, reuse, extend, and debug
Light forms that interact with decoupled code in objects provide you another important benefit. With objects,
shared classes, delegates, and interfaces completely disconnected from the UI, the UI can change in any way it
needs to, to accommodate the user, without affecting a single line of code in the objects (where the action
happens). In other words, your UI can be located on a watch, a PDA, a telephone, a server, a workstation, a
564
