In a previous article, I mentioned that you should consider building a customization mechanism into your software if you think you’ll need to customize it in order to make a sale. This is frequently a requirement for large, expensive enterprise software.
So, how would you go about this? Here are a few ways that I’ve done it:
Plugins
If you want to provide a way to allow others to customize your software without having access to its source code, then plugins are the way to go.
Plugins are a common way to add additional functionality to an application. You define a plugin format such that someone else can create some code that your application can use just by dropping it in. Most of the development IDEs out there support this mechanism in some way. Firefox also has a great plugin capability which they call “Extensions”.
I’ve had success using .NET to create plugins. An end-user can just create a class library using an interface you have defined and drop the resulting DLL into your plugin folder. This ought to work equally well in Java, although I have not done it myself. REALbasic does not have reflection yet, but it does have RBScript, which can be used to add new functionality. RBScripts are just text files, but you can use them very similarly to plugins.
A problem with plugins is that they may not give you the level of customization that you need. They are isolated and are really great at providing new function points, but may not the best way to change overall business flow, for example.
Hooks
Similar to plugins, but a little more invasive is the concept of hooks. With these, you identify points in your base product code where you want the ability to be able to call customized code. These points simply call unimplemented routines. These routines are replaced with customized code as necessary (the customized code is maintained separately from the base product code). A complete build of the customized product includes both sets of code.
This has the benefit of allowing you to upgrade your base code without breaking the customized code, at least in theory. However, since there is no restriction on what the customized code can do you might find that sometimes something doesn’t work right, but most of the time I find it to be effective.
A downside to hooks is that it can be hard to guess where to put the hooks. You inevitably run into a place where you need a hook, but do not have one, forcing you to upgrade your base product just to add the hook. In addition, unless you give them source code, your customers will not generally be able to access your hooks.
Overriding
This may not be great, but I have used it and it does work. You could create your application structure using inheritance to support a customization layer. Essentially your code would be structured like this:
Base System:
Base Code Layer -> Customization Layer -> Usage Layer
Customized System:Customization Layer
In the Base System, the Customization and Usage Layers do not contain any actual code. The User Layer is just the final classes that are referenced by the rest of your code.
To customize, you simply add code to the customization layer to either extend or override what the base layer does. This customization layer should be stored in a separate source repository so that you can have different customizations for different customers. Your build would pull down the base and user layers, overlay a specific customized layer on top of it and then build it all together.
This technique is more complex than I like because it requires lots of virtual methods in your base layer and a really good understanding of the object model, but it will allow you to provide customers with powerful customizations, while still retaining the ability to upgrade the base layer.
Mix and Match
It certainly possible to mix each of these techniques together, particularly when you want to allows others to customize your product while at the same time retaining a more powerful mechanism for your in-house staff to use.
What sort of techniques do you use?