Reduce dependencies between modules in blackmisc

[oktal3700]

First step in modularizing libraries and making code more maintainable.

"Levelization" in the language of John Lakos is a set of techniques for reducing the dependencies between modules thereby making them easier to modify without breaking the whole system.

[oktal3700]

Cyclic dependencies hurt modularity and inhibit maintainability. I have started by concentrating on the modules in the root directory of blackmisc. I wrote a perl script to identify the interdependencies. I have methodologically worked through the results, breaking dependencies where able. Some are so intertwined that some planning is required. The worst ones are:

1. CIcon
2. CLogCategory
3. CPropertyIndex and CVariant
4. IOrderableList
5. ITimestampObjectList

[123] will be solved using a combination of Demotion and Dumb Data techniques. [45] are still an open question; some form of Escalation may be indicated. From the levelization techniques described in Large Scale C++ Software Design (1996) by John Lakos:

• Escalation: the dependent functionality is moved into a new higher-level module, which can depend upon the modules on both sides of the cyclic dependency. So e.g. A⇔B becomes A⇐C⇒B.
• Demotion: the dependent functionality is moved into a new lower-level module, which can be depended upon by the modules on both sides of the cyclic dependency. So e.g. A⇔B becomes A⇒C⇐B.
• Dumb Data: a special case of Demotion in which the new "module" is so low-level that it is not actually a module, just some object(s) of fundamental type.

For CIcon this could mean that value classes' toIcon methods should return enums instead of actual CIcon instances. For CLogCategory it may mean that getLogCategory methods could return plain strings instead of actual CLogCategory instances.

For CPropertyIndex it may mean that the methods of Mixin::Index should operate on instances of QVariant and a new class e.g. CProperty which can be constructed from a CPropertyIndex and provides a subset of its functionality. Or maybe these methods should be replaced with a more declarative approach in which a static method returns metadata about the properties of the class. In preparation for this step it may make sense to refactor the property index enums to avoid the ugly "global" enum values.

[oktal3700]

Status update: pushed a work in progress.

The remaining cyclic dependencies seem to be these:

• statusmessage ⇔ statusexception
• statusmessage ⇔ logpattern
• variant ⇔ variantlist
• icon ⇔ iconlist

[oktal3700]

Pushed a new WIP. The remaining problem modules are aircraftmodel and aircraftmodellist: