Introduction: Alan Griffiths

• Senior Systems Consultant for Experian Limited
• Architect of flagship MA division's Micromarketer product
• C++ SIG organiser
• Occasional "Overload" contributor
• http://www.octopull.demon.co.uk/c++/properties.html

Purpose of "Properties"

The Micromarketer system architecture:

• GUI
• Business abstractions
• Core functionality

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

A problem was encountered with first version of Micromarketer. This is exemplified by the following story:

A main part of the user interface is a MSWindows "Explorer" type browser which allows the user to manage "components" within "projects". Components can be renamed within the browser, and also via "Property Dialogs" and "Wizards". The logic that validates the name change was implemented differently in the "Browser".

This had the effect that the browser would allow an "!" in a component name, but if the property dialog was subsequently displayed and cancelled the dialog's validation logic kicked in objected to this character and dropped the system into an endless series of error messages.

This problem came up in it's generic form in a design review, and after a discussion of some ideas I wrote up the best of them in a "properties" design paper. (Which forms the basis of this talk.)

Problem Statement

Components [in the Business Abstraction layer] have attributes (e.g. names) that may be accessed and amended via the user interface (e.g. wizards & property sheets). The mechanisms for validating these updates should be independent of the user interface. (For example, at present the rules applied when changing the name of a view in the browser and in the property sheet are different.)

In addition, changing some component attributes via wizard page/property sheet may impact another wizard page or property sheet (because the value is displayed there, or because there are some options that may be enabled/disabled accordingly). At present the wizard pages or property sheets need to implement these notifications - this is error prone, hard to maintain and breaks encapsulation.

Changes may not be made directly on the component because:

1. the component may not yet exist,
2. the changes may not be complete, or
3. because the wizard/properties may be dismissed.

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

Proposed Solution

Class diagram

The Property Template

The behaviour of a "property" is generic (and is templated on the value type):

1. it holds a value,
2. if an attempt is made to change a value then the change is "validated",
3. "interested" objects are notified of changes to the value.

Validation of changes will be the responsibility of the ComponentProperties class (e.g. M6XProperties). The wizard, wizard pages, and, possibly, the ComponentProperties register as "interested" objects.

Component Properties Classes

Corresponding to each abstraction layer component type (e.g. M6XComponent) there should be a ComponentProperties class (e.g. M6XProperties) . This is implemented in the abstraction layer alongside the component and exposes the accessible attributes of the component as "properties".

The ComponentProperties class implements any validation methods required for the component attributes (and attach them to the appropriate "properties"). In many cases it needs to implement a validation check that cross checks properties for consistency. This can be used to maintain an additional "isValid" property.

Each abstraction layer component has a factory method (or a constructor) and instance methods "getProperties" and "setProperties" all of which accept the corresponding ComponentProperties class.

Object interactions

Interaction diagram

When a wizard (for example) is invoked it creates an instance of the corresponding ComponentProperties object. (The ComponentProperties object could then be initialised from an existing component if this is appropriate - which is the case for a properties dialog.)

The wizard adds "listener" methods on itself to selected properties. That is, to any properties that affect the wizards globally - for example requiring adding/removing wizard pages, or enabling/disabling "finish".

Each wizard page is initialised with a reference to the wizard's ComponentProperties object. It can then associate the corresponding dialog control(s) with the property and add "listener" methods on itself to any properties that affect the behaviour of the page.

When the "Finish" button is selected the component is constructed using (or has its attributes set from) the ComponentProperties object.

Further details