Sponsored Links
Build user interfaces for object-oriented systems, Part 2: The visual-proxy architecture
A scalable architecture for building object-oriented user interfaces
- Feedback
- Discuss
"Build user interfaces for object-oriented systems": Read the whole series!
- Part 1. What is an object? The theory behind building object-oriented user interfaces
- Part 2. The visual-proxy architecture
- Part 3. The incredible transmogrifying widget
- Part 4. Menu negotiation
- Part 5. Useful stuff
- Part 6. An RPN-calculator application demonstrates object-oriented UI principles
The problem
This month's column expands on the ideas presented in July's column, "Building user interfaces for object-oriented systems, Part 1," by actually implementing a simple system for doing forms-based I/O. The main principle that I'm demonstrating here is organizational: I'll show you how to organize your code in such a way that arbitrary forms can be constructed automatically, minimizing the coupling relationships between the GUI subsystem and the underlying logical model (the "business" objects, if you will).
One approach to this problem is to have all objects render themselves on the screen (with a draw_yourself(Graphics here) message). Though this sort of simplistic approach can work for trivial objects, it's not a realistic solution for several
reasons. First, actually embedding graphical code into the methods of a model-level class is usually a bad idea for maintenance
reasons. The graphical code is usually scattered throughout the methods of the object, and it becomes too difficult to make
minor changes in implementation as a consequence. It's also very difficult for an object to display itself in more than one
way. This month, I'll look at an approach that doesn't have the problems of Model/View/Controller (MVC) architecture, but
that accomplishes the main goal of the Microsoft Foundation Classes (MFC): the decoupling of the abstraction (model) and presentation
(view) layers.
Attributes
The main way to get around the problems caused by simply asking an object to display itself is to make a distinction between the entire object and its individual attributes. In the world of object-oriented design, an attribute falls under one of the following definitions:
- A characteristic of some class of objects that serves to distinguish it from other classes of objects. For example, the notion of a salary distinguishes a class of objects (employees) from a broader class of objects (people in general). People without salaries are simply not employees -- they're volunteers, derelicts, CEOs of software startups, and the like, but they aren't employees. All employees, then, must have a salary, so salary is an attribute of an employee.
- A characteristic of some object that serves to distinguish it from other objects. An employee's name, for example, serves to distinguish individual employees from each other. Two completely unrelated classes (person and microprocessor, for example) could have name attributes, so the class-based test above doesn't work, but the name does serve to distinguish one employee from another employee (or one microprocessor from another microprocessor).
The operations of a class are attributes as well: what an object can do certainly distinguishes one class of objects from another.
- Feedback
Resources
- The code in this article, along with an index of all the articles I've written for JavaWorld, can be found on my Web site, in the "Articles" section. http://www.holub.com
Design patterns
Design PatternsElements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley, 1995), is a cookbook documenting many patterns of object/class interaction that recur regularly in good object-oriented designs. All experienced object-oriented designers will recognize these patterns immediately from their own work, and folks who are learning object-oriented design can save themselves a lot of hard work by using the patterns described here from the beginning. Though any cookbook approach to design is ultimately limiting (to use a cookbook, you have to know how to cook), this book is invaluable to people learning the design process or wanting a common vocabulary to describe parts of their designs to other designers. It can save you an enormous amount of time
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201633612&from=NCN454 - Pattern Oriented Software ArchitectureA System of Patterns, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal (John Wiley & Sons, 1996 ) covers more or
less the same ground as the Gang of Four book, but it covers some additional material as well. In particular, the Model/View/Controller
and Presentation/Abstraction/Control architectures are discussed in depth
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0471958697&from=NCN454 - Object-Oriented ProgrammingAn Evolutionary Approach, 2nd ed., Brad Cox and Andrew J. Novobilski (Addison-Wesley, 1994). Brad Cox first came up with the notion of a "pluggable component"
(which he calls a "Software IC") in the context of the Objective C programming language. This book discusses both the Software IC and the language
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201548348&from=NCN454 - Patterns in Java, Vol. 1, Mark Grand (John Wiley & Sons, 1998), is essentially a rehashing of the Gang of Four book, but much more readable, and with
examples in Java rather than C++. Grand does cover several patterns not covered by the Gang of Four, too
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0471258393&from=NCN454 - Patterns in Java, Vol. 2, Mark Grand (John Wiley & Sons, 1999), includes a very good chapter on UI design patterns, among others
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0471258415&from=NCN454 -
Reuse
"Flight 501 Failure Report," from the Inquiry Board of the European Space Agency, is an account of the launch and subsequent self destruction of the Ariane5 satellite booster. It's a great real-world example of why a "pluggable component" architecture is problematic in the real world
Usability Engineering, Jakob Nielsen (Morgan Kaufmann Publishers, 1993), is a good introduction to writing programs with usability in mind">http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.htmlUI design
Usability Engineering, Jakob Nielsen (Morgan Kaufmann Publishers, 1993), is a good introduction to writing programs with usability in mind
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0125184069&from=NCN454 - The Design of Everyday Things, (Doubleday, 1990), Donald A. Norman, obstensibly is about industrial design, but is really about good design in general.
Using what he calls "user-centered design," Norman describes in detail why some designs are so frustrating to users and others
are not. Norman talks in depth about how to work with people to end up with good designs for everything from faucets to computer
programs. It's an amusing book that gives great advice about a serious subject
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0385267746&from=NCN454 - "Interface Hall of Shame," (Isys Information Architects), is a great compendium of bad UI design. There's also a good UI hall
of fame, but the bad UI section is more amusing. Though Microsoft, as usual, provides a rich set of examples of how not to
do things, they are by no means the only entrants
http://www.iarchitect.com/mshame.htm - Designing Visual InterfacesCommunication Oriented Techniques, Kevin Mullett and Darrell Sano (Prentice Hall, 1995), is essential reading for designers of data-entry systems. Particularly
useful discussions of dialog layout, data-entry forms, and so on
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0133033899&from=NCN454 - The Visual Display of Quantitative Information, Edward R. Tufte (Graphics Press, 1983), is a beautiful book that describes the "other side" of the U/I equationhow to present data to the user in the clearest possible way. Mullett describes the input side of the equation, Tufte the output side. Tufte's other books ({i Visual Explanations} and {i Envisioning Information}) are also worthwhile.
- About FaceThe Essentials of User Interface Design, Alan Cooper (IDG Books, 1995). Ironically, the author of a great book about UI design is also the "father of Visual Basic,"
the tool responsible for many of the worst user interfaces ever foisted on the computing public. Cooper has a lot of opinions,
some of which I agree with and some of which I don't. (In particular, I don't think of a program as a UI with intelligent
warts hanging off of it, as Alan seems to do). Nonetheless, Cooper is always entertaining, and there's a lot of good advice
here
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1568843224&from=NCN454
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2008 Network World, Inc. All rights reserved.