Get down with the ValueModel approach to OOP

There is a very nice incarnation of the MVC paradigm called ValueModel that was invented at Smalltalk-oriented Xerox-spinoff PARC Place Systems back in the 1990s.

ValueModel was part of their VisualWorks application. As far as I know, that was the most highly evolved MVC-oriented GUI application programming framework devised in Smalltalk.

If you download the Application Developers Guide and do a search on ValueModel - you will get treated to some nice diagrams and code. Not a lot, but they are the right ones to examine. There is a page with all the VisualWorks documentation, if you want to browse everything.

The idea of the ValueModel approach is simple. So simple, in fact, it is amazing most people do not hit upon it as soon as they are told of MVC and start using it awhile.

1. Every value that participates in the GUI (by being displayed as a value or affecting the display or being altered by a control that affects the model) is made a Model object itself. Nobody every said values could not be model objects, right?!
2. These ValueModel objects are wired together, using adapter objects when necessary (to do stuff like scaling, type-conversion, value-mapping, etc.)
3. Views view them, Controllers control them, women want them. (Okay, not too sure about the last but you get the idea.)

What this approach, compared to conventional non-MVC and even many so-called MVC approaches does, is allow you to decimate the application-specific and domain-specifc logic contained in the GUI (e.g., model, view, page, component) classes of an application.

Instead the application logic, domain logic, business rules, and so forth - are in the model. The view components and controller components wind up being application-independent things.

The savoir-faire comes in when you wire these objects together. Mostly, the wiring is done at initialization time. For the application and after loading new data from the database and/or data files.

Who uses this approach?

Well, people doing simulations pretty much have been doing it a long, long time. Do you think that people design/test mission-critical complex systems in BASIC or assembly language? Think again.

One place where a ValueModel-like approach is revealed in all its glory is in the VRML 2 3D graphics language. Take a look at the ROUTE statement, and how it is used to wire values together throughout the scene.

A VRML scene is one big huge value constraint system. Values somewhere in the model are changed, like independent values in a mathematical model. Dependent values, naturally, change as a result. And values dependent on those values consequently change as well. Consequent is a good word to keep in mind, in fact, when thinking about this stuff.

What you do is design the model, identify the dependencies, and mark them down explicitly. That is stuff you are supposed to do anyway. You are a designer, after all - not a typist or sketch-artist. Basically, you simply do this in a machine readable fashion - instead of stopping as soon as the ink has dried on the back of a paper napkin.

As soon as you get the model all wired up together with value models, adapters, model collections - you can write your unit tests. You can actually run them, and wind up testing a huge percentage of your application logic and business rules.

Once that is done, you write the controllers - and test them.

Finally, you are ready to do the views, and they should be pretty simple. If you abstract them nicely, you can have Test versions of the views for each datatype and use those in your tests of the views.

The finished application uses GUI-specific controllers and views, based on the same super classes that the test controllers and views use.

That way, whether you are using Swing, WinForms, Wx, Tk, or whatever as your GUI - shouldn't matter. Only the concrete subclasses of the abstract datatype-specific views and controller classes change.

If you want to read another description of this technique, research the Typed Event Channel design pattern. It was described back in the late 1990s, a couple years after the original GoF Design Patterns book came out.

Like MVC is a special application of the Observable-Observer pattern, ValueModel is a special application of the Model-View-Controller pattern.

While I suspect this technique is used in quite a few commercially successful applications, you cannot pop most of them open like you can a framework or an open source program.

One program you can see the technique in because it is purposely completely above surface in the application, is the Quartz Composer appilcation from Apple Computer.

This application comes with the free Developer Tools that are bundled on an extra DVD included with each Macintosh computer. If you are a developer, and have a Macintosh - take a look at it. If you are not a Mac-owner, then drop by Apple's website and read up on it.

Quartz Composer is just one of many in a long line of applications that have used this approach.

Not many people think of it, but the design patterns Gang of Four (GoF) actually did have a professional as well as academimc life before they wrote Design Patterns.

Well, some of those guys wrote programs very much like that, including one designed to generate multimedia music and video presentations.

And basically, that is what Apple's QC is, writ prettier on a much nicer modern GUI/OS canvas.