Question

I would be curious to know if there is a design/architectural pattern for creating applications that have multiple editions (for example how Windows has Home, Standard or Ultimate editions).

The main idea is that I would like to create an application that gives the users different features, depending on the edition that they have (basic, advanced, full). Someone suggested using plugins… is this a good aproach?

Thanks!

Answer 1

There are a number of options.

Conceptually, the simplest thing is to build 3 different applications, re-using where you can. So, you might have an “engine”, providing shared functionality, and 3 separate applications running on the engine – “basic”, “advanced”, “full”. This is kinda what the MS operating system flavours are – the engine is the basic operating system, and the different editions contain different applications built on top of the engine.

The benefit of this route is that you can create a conceptually valid product – you don’t have lots of dependencies between editions, and if the “full” edition decides not to include features from the “basic” edition because they don’t make sense, they don’t have to worry about breaking that dependency.

The second model is to build a single application, and control its behaviour through configuration – either at build time or at run time. “ifdef” for instance allows a single C code file to target different operating systems; the number of processors supported by different flavours of the same SQL database engine might be controlled by run-time configuration.

This has the advantage that you have a single code base to manage, but introduces very tight coupling between the editions, and quickly becomes unmanageable.

Lots of applications use the “plug-in” model; this is a variation on the first option, in that it requires you to build a framework application first, and the capabilities of each edition are limited by what your framework can do. Many games ware designed in this way, and the difference between versions basically depends on which plug-ins ship with the game.

This is architecturally very clean, but presents real risks to the project – your smartest developers will all want to work on the framework, and nobody wants to work on the actual product; if your framework developers guess wrong on what the real requirements are, you end up with a brilliant framework that supports the wrong product. Also, the framework tends to focus very much on computer sciencey issues like logging or plug-in configuration, and not so much on the real business questions. I’ve seen this at first hand, and it was kinda tragic.

Unless you have unlimited time and budget, I’d start with option 1, and evolve to option 3 once you’ve got your first release out the door.