About the cf::GuiSys::WindowT::EditorData class member

[Carsten]

Dear Shiv, hi all,

as promised before I'd like to provide some thoughts about member EditorData (of type EditorDataT*) of the WindowT class (all in namespace cf::GuiSys).

The key idea is that the WindowT class is one of the central classes of the GuiSys: A GUI is in fact just a hierarchy of WindowT's. As such, the WindowT class is well designed, it has children and a parent, and many of its members are in "private" access section. [1]

However, the WindowT class has initially not been designed with a GuiEditor in mind: when the WindowT class was written, a GuiEditor was in the distant future and had no place in the class design of the GuiSys.

Until today, a GuiEditor is, wrt. class design, a very separate program concept. Regarding the WindowT class, two important properties that arise with a GuiEditor are:

• The GuiEditor needs access also to the private members of a WindowT, and
• it needs additional WindowT class members for its editor-specific purposes (e.g. for the current state of selection, and anything else the editor might wish to save with a WindowT instance).

However, we don't want to change the interface of the WindowT class in order to meet the above requirements of the GuiEditor, because that would destroy encapsulation (and thus an important part of the class design) and force implementation details of the GuiEditor into the WindowT, which is very bad, because the GuiEditor is a separate program (changes to the GuiEditor should whenever possible not force changes to the WindowT class - just imagine we were writing more than one GuiEditor (e.g. a keyboard and text based one for purists), then there would be conflicts and chaos in WindowT if every editor implementation wanted to adapt the WindowT class to its specific needs).

In order to overcome these problems, we introduced the EditorDataT class, which is a friend of WindowT. Moreover, the EditorDataT class is supposed to be an (optional) member of each WindowT instance, and it can be augmented with arbitrary additional data by deriving from it. The EditorDataT class also knows the WindowT instance it is a member of, which means that you can build a hierarchy of EditorDataT objects that mirror the hierarchy formed by the actual WindowT instances.

This solves the two above mentioned problems: The friendship of the EditorDataT class with the WindowT class solves the problem of encapsulation, and its extensibility by deriving other classes allows for a hierarchy that closely mirrors that of the WindowT's, but can store arbitrary additional editor-specific data.


This is a pretty high-level overview, and currently it seems that the existing EditorDataT class needs additional methods for querying the associated WindowT instance before it can be useful for the purpose described above (EditorDataT is only half-finished currently).

As always, please just let me know if you have any question, I'm happy to explain in greater depth and/or detail.


[1] This has recently been changed though - most important members are now in "public" access section so that also derived classes like ListBoxT can have WindowT children and still access their members directly - but the concepts provided above still remain true.