|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
"Build user interfaces for object-oriented systems": Read the whole series!
I've actually written about this sort of stuff before, but not for JavaWorld, and the articles I've written now are out of date, so I thought I'd take another stab at the problem of describing object-oriented systems from the UI designer's point of view. Hopefully, by the time I'm done you'll understand in general terms how a UI in an object-oriented system has to work. I'll also endeavor to clarify why not one of the RAD tools on the market today (Visual Café, Visual Age for Java, Visual J++, JBuilder -- you name it) is usable if your final goal is a well-crafted object-oriented system.
This month's article, then, is a primer on objects. It describes what an object is (or what it should be in a well-constructed system) and how objects should interact with one another at runtime. We'll also see how object-oriented systems, by nature, have UI-design requirements that simply don't come up in procedural systems, so are rarely implemented correctly by procedural programmers who are moving into an object-oriented environment. In subsequent articles, I intend to apply these principles to real code so that you can see how it all works. Next month, for example, I'll start looking at a forms-based I/O system that works well in an object-oriented environment. This article is a bit on the long side, but the concepts are essential, and I want to be as thorough as possible in my coverage.
Bjarne Stroustrup, the inventor of C++, once characterized object-oriented programming as "buzzword-oriented programming," and certainly one of the most abused (or at least misunderstood) buzzwords in the pack is object itself. Since the idea of the object is so central, a full discussion of what objects actually are is essential to understanding object-oriented systems and their needs, particularly from the perspective of the user interface.
First of all, think of an object-oriented system as a bunch of intelligent animals (the objects) inside your machine talking to each other by sending messages back and forth. Think object. Classes are irrelevant -- they're just a convenience provided for the compiler. The animals/objects that comprise our system can be classified together if they have similar characteristics (if they can handle the same messages as other objects in the class, for example), but what you have at runtime is a bunch of objects, not classes -- animals, not their descriptions. What we programmers call classes are really classes of objects. That is, a set of objects are of the same class if they have the same properties. This usage is just English, and is really the correct way to think about things. We're doing object-oriented design, not class-based design.