Java Reference
In-Depth Information
When we did so, we lost many of the specialized optimizations that the
graphical framework designers built in, such as event filtering and
repainting. The original Java architecture for user interfaces, the
Abstract Window Toolkit ( AWT ) library, also had this problem. It was
easy to produce heavily layered user interfaces. All of the inheritance lay-
ers and the generalized event management without adequate filtering
made it easy for one user event to generate thousands of messages with
simple gestures like resizing. The term “event storm” was coined to
describe this common antipattern.
Early versions of a fully object-oriented operating system called Tali-
gent also suffered from the over-layered user interface antipattern. I
worked alongside many of the brightest minds in the industry in a
department responsible for porting Taligent to other operating sys-
tems. The fundamental premise of the operating system was that every-
thing was an object, from semaphores to file handles. This came at a
price, but it was one that we thought that we could manage. As Apple
and IBM worked to merge IBM 's microkernel architecture with Apple's
critical user-interface technology and operating system abstractions,
scope grew and fundamental assumptions also changed. We would
work to integrate massively complex systems at the last hour. The
debugging process was much faster than I would have thought possi-
ble, but the thing was s-l-o-w. There were simply too many layers for
the operating system or supporting hardware. We had not even layered
on user applications yet.
In the mid- to late 1990s, early persistence frameworks, which allowed a
network of objects to be transparently saved to a database, were also
perilous. Many customers rolled their own. Very few were successful.
The reasons were twofold. First, the frameworks, implemented on rela-
tional databases, could not take advantage of many of the features of the
database engines for sorts, stored procedures, or complex queries.
When these functions were handled at the application layer, the perfor-
mance was hideous. Second, the frameworks were usually very complex,
adding many layers to the most basic of object models. When complex
and heavily layered object models are defined, even the most robust
architectures can break down.
Not all of these projects had happy endings. Some of the time, simplifica-
tion with faster hardware and better designs were able to take up the slack
and save us. Occasionally, we never recovered. When you're developing
complex object-oriented designs, you must build layers for simplicity and
Search WWH ::

Custom Search