Java Reference
In-Depth Information
started searching for the antipattern, I found what looked like the same
wretched application at many different places and different circumstances. It
didn't matter what industry. It didn't matter what language was used for the
implementation, though Visual Basic was the most common. The problem
was more common to inexperienced programmers, but hard-core program-
mers were not immune. It was the simplest of antipatterns: an unstructured
application consisting of a single, monolithic procedure fired by a user inter-
face event. In a nutshell, this problem is a lack of decomposition. A simple
example is an 11
KB
application with 10
KB
hanging off a pushbutton, as in
figure 3.1. Many readers recognize this antipattern even before further
description. This pushbutton is “magic” because it does most of the work for
the application within a single function. These applications make me think of a
fat plumber in tight Spandex. The proportions are comical and the results can
be disastrous. The applications are obviously ugly and difficult to maintain,
but the root cause or the refactored solution is not always obvious.
10 KB Script
Figure 3.1
The Magic Pushbutton consists of a block of code hanging off a
pushbutton and represents event-driven programming at its worst. It
was most prevalent in the mid-1990s when Visual Basic, PowerBuilder,
and similar languages were at their strongest.
OK
The Magic Pushbutton can actually be traced to the graphical tools that broke
onto the programming scene in the early 1990s. The tools ushered in drag-
and-drop programming. Like the ancient trading clipper ships that carried rats
with new diseases hidden among the treasures they bore, these tools brought a
new kind of antipattern. If you bring up an old copy of Visual Basic, it's easy
to see why. The program, and many others like it, first presents a screen that
allows the development of the user interface. The programmer can rapidly
prototype the user interface and then attach the necessary logic. The sublimi-
nal message is clear: “Go ahead and start. You're building a program, not a
house. You don't need a foundation. With this new tool, you will have plenty
of time to design what you need down the road.” For some applications, this
approach works because the back end is already defined. The back end might
take the form of components built by someone else, stored procedures, or
existing transactions. For these applications, the view and model are cleanly
separated.
