Building user interfaces for object-oriented systems, Part 1

What is an object? The theory behind building object-oriented user interfaces

1 2 3 4 Page 2
Page 2 of 4

Rather than take my word for it, let's explore a few of the maintenance problems that arise when you try to develop a significant program using the MVC architecture. In the simple example above, you're tasked with adding an employee ID to every name in every screen that displays employee names. In the RAD-style architecture, you'll have to modify every one of these screens by hand, modifying or adding widgets to accomodate the new ID field. You'll also have to add facilities to the Employee class to be able to set the ID. And you'll have to examine every class that uses an Employee to ensure that the ID hasn't broken anything. For example, comparison of two Employee objects to see if they're equal must now use the ID, so you now have to modify all this code. If you had simply encapsulated the identity into a Name class, none of this work would be necessary. The Name objects would simply display themselves in the new way. Two Name objects would now compare themselves using the ID information; your code that called fred.compareTo(ginger) or fred.equals(ginger) wouldn't have to change at all.

You can't even automate the update-the-code process, because all that WYSIWYG functionality (that's so often touted in marketing buzz) hides the code-generation process to the extent that it's impossible to modify machine-generated code safely. In any event, if you automatically modify machine-generated code, your modifications will be blown away the next time somebody uses the visual tool. Even if you don't use the tool again, modifying machine-generated code is always risky, since most of the RAD tools are very picky about what this code looks like, and if you do something unexpected in your modifications, the RAD tool is likely to become so confused that it will refuse to do anything at all the next time you do need to use it. Moreover, this machine-generated code is often miserable stuff, created with little thought given to efficiency, compactness, readability, and other important issues.

The real abomination in the RAD-style architecture is the "data-bound grid control," a table-like widget that effectively encapsulates the SQL that's needed to fill its cells from a database. What happens when the underlying data dictionary changes? All this embedded SQL is rendered meaningless. You'll have to search out every screen in the system that has a data-bound control and change that screen using a visual tool. Going to a "three-tier" system -- where the UI layer talks to a layer that encapsulates the SQL, which in turn talks to the database -- does nothing but make the problem worse, since the code you have to modify has been distributed out into more places. And in any event, if the middle tier is made of machine-generated code (usually the case), its very existence is of little use from a maintenance point of view.

All this modifying-every-screen-by-hand business is way too much work for me. Any time savings you may have gained by using the RAD tool to produce the initial code are more than lost as soon as the code hits maintenance.

The appeal of these systems often lies in familiarity. They help you program in an unfamiliar object-oriented language using a familiar procedural mindset. This sort of I-can-program-FORTRAN-in-any-language mindset, however, precludes your ability to leverage the real maintenance benefits of object-oriented systems. I personally feel that there's absolutely no reason to use Java (or C++) unless you are indeed implementing an object-oriented design. C++ in particular has so many problems that it's not worth messing with if you aren't going to take advantage of its strengths, and even Java isn't the height of simplicity -- it's simple only when compared to C++. You're better off just using C if you want to write procedural systems.

On the other hand, if you are doing an object-oriented design, a language designed to implement object-oriented systems (like Java) can make the implementation dramatically easier. Many C programmers try to program in Java as if they were programming in C, however, implementing procedural systems in Java rather than object-oriented systems -- in other words, writing really awful code. This practice is really encouraged by the language, which unfortunately mimics much of the syntax of C and C++, including flaws like the messed-up precedence of bitwise operators. Java mitigates the situation a bit because it's more of a "pure" object-oriented language than C++. It is therefore harder, though not impossible, to abuse. (A determined individual can write garbage code in any language.)

Related:
1 2 3 4 Page 2
Page 2 of 4