20 October 2005
Who's up for a game of "Name that Design Pattern?"
The PreferencesViewer control containes a
PreferenceList consisting of zero or more
Preference objects. The PreferencesViewer
can then obtain a PreferenceViewer (note the singular
vs. plural) for each Preference by calling
Preference.GetViewer(). This all works very well, and
really isn't particularly exciting to discuss.
Now, enter the PreferenceLibrary: a toolbar of
possible preference types. The user clicks a button with a pretty
icon (a clock, perhaps) and the toolbar produces the corresponding
type of Preference object (a
TimeOfDayPreference). This too would be trivial
if I were willing to accept that I knew in advance what types
of preferences existed. I, being a stubborn OO designer, am not
willing to accept that.
Here's my solution; what do you think? A Preference
shall have a static .PreferenceButton property, which
returns an instance of PreferenceButton (a subtype
specific to each type of preference, of course). The
PreferenceLibrary, then, will have a static method that
accepts such an object and uses it to get the appropriate icon, and as
a factory to get an instance of the original Preference.
I can add these to the library statically, now, by writing lines like:
PreferencesLibrary.AddPreferenceType(TimeOfDayPreference.PreferenceButton)
Holy circular references, Batman!