Platform Trick and Tips
One of the projects I am working on as part of 2010 is advancing the platform built for my day job as Security Console. But as part of the enhancements I need to modify the current structure to make better use of platform infrastructure. To make life easier for not only me as the engineer but for the people who will be doing maintenance on the application when I move on to the next project, I borrowed some ideas from the past that I worked on.
First, I remember back to when I started using Windows. It was Windows for Workgroups 3.11 and unlike the various explorers that were introduced in Windows 95, everything had a manager. If you wanted to start a program, it was the Program Manager. If you wanted to set up a printer, you used the print manager. If you wanted to located that file, it was the File Manager.
Second, I remember back trying to integrate hooks into Microsoft Outlook. The features of Outlook are accessible via a COM interface. If you were annoyed by COM as much as I was, a more simpler and logical interface was to provide an extension DLL that implemented the interfaces needed to provide the custom integration I was looking to do. There is essentially an interface to implement for many things that you can connect to with in the application.
I merged these two ideas from the past to create the customizable platform that I am working on today. The components of the framework that can have custom extensions providing additional features are maintained by framework managers. I have provided managers to handle applets, configuration property dialogs and hooks to the main window to display data. A single instance of a manager exists with in the framework and handles the components implementing the interface the manager is responsible for maintaining.
Another major component is having the defined interface the manager is responsible for handling. This means there is an interface class associated with each manager. These interface classes bear class names that begin with ISC which stands for Interface into Security Console. In the past we used ISC to designate a class was specific to handling a feature of our company's product. However, starting a class name with I is the standard indication of an interface class, hence the change. With my project, classes that had the ISC prefix were simply renamed to SC to indicate they are specific to the project and not an interface.
To extend the platform to perform application handling, you essentially need to build an applet that inherits one or more interface classes. All applets have to inherit the ISCApplet interface and are installed into the framework's applet manager. Other managers query which applets expose interfaces they can work with. How do they do this? There is a C++ keyword that you use to determine if an object with multiple inheritance is derived from a specific class. That keyword is dynacast and it takes the format:
ClassName* dynamic_cast< ClassName* >( variable );
If the variable is a class that inherits the class specified in ClassName than a pointer to that class object is returned. If variable is not derived from the class than a NULL pointer is returned. Suppose I have 5 applets classes but only 3 inherit the ISCConfigurationPanelExtension, I can enumerate over all the appets and perform a dynacast to obtain a pointer to the ISCConfigurationPanelExtension. If I obtain such a pointer, than the framework's configuration panel manager can handle those instances. If I get a NULL pointer, I know that applet does not have a configuration panel item and can be skipped.
In this stage, I am taking exsiting code and re-arranging it into an easier to maintain platform-applet model which means there are methods that are currently implemented in the wrong space. While I can move the implementation to the new interface based method, finding all the locations in the code to modify can be tricky especially if I am not ready to remove the old implementation yet. To make sure I don't loose track of what needs to be switched from old to new I am making use of the following derictive:
__declspec(deprecated("Method is depricated. Use NewMethod() instead"))static int Method();
This is placed in the headers where the existing Method is declared. When the project compiles, warning are issued so when I perform a build all I have records of where all the old methods are referenced and a count of how many need to be switched before I can remove the old method without generating compiler errors.
Using these basic tricks I am able to port the project over to a more robust code base and keep track of changes that need to be made so I don't forget modifications prior to generating that final build.
