Title: Almost a Pattern

This article describes a recurring problem in program design and presents both a method of design and an implementation of part of that solution. The problem in question is that of separating the application logic that governs the changes a user may make to objects within the application from the detail of the user interface.

I first documented this problem and solution as part of the development of Experian's "Micromarketer" application. This formed the basis of my presentation at the AGM. Kevlin Henney informs me that he's used a similar design for a similar problem. (This makes two uses: one more and I can call it a pattern!)

Many applications (including "Micromarketer") can be divided into three conceptual layers:

Each of these provides services to the layers above and makes use of services provided by the layers below.

Abstraction layer components have attributes (e.g. names) that may be accessed and amended via the user interface (in the case of Micromarketer, wizards & property dialogs). The mechanisms for validating these updates should be independent of the user interface. For instance, the same component attributes may be exposed through several parts of the user interface and the validation needs to be consistent.

Some early parts of Micromarketer were developed with the validation of changes in the user interface. It has proved difficult to ensure that these remain consistent. In particular it is possible to change the name of most component in three ways: via the component "browser" (similar to "Windows Explorer"), via the component properties dialog, or via a wizard. At one stage it was possible to place "invalid" characters into a component name via the browser and to subsequently crash the property dialog by cancelling out of it.

A related problem is that changing some component attributes via wizard page/property sheet may impact another wizard page or property sheet. This could be because the value is displayed there, or because there are some options that may be enabled/disabled accordingly. In practice an approach in which the wizard pages or property sheets implement these notifications has proven error prone, hard to maintain and clearly breaks encapsulation.

Finally it may be observed that changes may not be made (and validated) directly on the component because:

Consequently, the wizard/property dialog needs to keep a copy of the component attributes.

The following code outlines an implementation of the "Property" generic used in the above solution (full source code has been was supplied - I presume it will find its way onto the C Vu disc.):

template<typename MyValueType> class M6Property
{
public:

A constructor for an unvalidated value:

M6Property(MyValueType initValue);

This constructor accepts both an initial value and an object and a method on that object that provides the validation check:

template<typename MyValidatorObject>
M6Property(
  MyValueType initValue,
  MyValidatorObject& validator, 
  int (MyValidatorObject::* method)(MyValueType));

Methods to access and modify the value. "setValue" returns a non-zero error code if the validation fails:

MyValueType getValue() const;
int setValue(MyValueType newValue);

Methods to allow objects (normally the "user interface" and the owning "component properties") to register for notification of changes to the value of the property.

template<typename MyListenerObject>
void addListener(
  MyListenerObject& listener,
  void (MyListenerObject::*method)(MyValueType));
template<typename MyListenerObject>
void delListener(MyListenerObject& listener, 
void (MyListenerObject::* method)(MyValueType));
};

As stated in the introduction Kevlin Henney of QA says he's used a similar implementation (although he's currently too busy to give details). In addition John Merrells (the overload editor) has used a similar idea in a client server environment in which the aggregated properties are passed across the network.