1. Use object-oriented programming: Abstract data type + inheritance + dynamic binding—for example, Company/List/ArrayList. Here multiple implementations of a module interface (such as descendent classes, Open-Closed, Single Choice, Liskov SP, and so on) can all be linked into one executable that selects a specific implementation (such as Abstract Factory) based on user input (such as command-line arguments). This is the simplest solution: just a single executable file given to users to install anywhere in their existing PATH. (On rare occasions, you might need to make extensions without modifying even a single module, in which case you can use Pluggable Factories ( C++ Report, Oct. 1999), but you should never use such added complexity gratuitously.)
2. Create shared libraries for each descendent. This leads to "DLL Hell." Shared libraries get my vote for the worst "innovation" in software since the days of goto, common blocks, variant records, equivalence, and implicit typing. They are the bane of those of us targeting multiple platforms. Even on one platform, users must install not just a single executable file but also a collection of object files (a certain version, a certain location) and then set their RPATH (modify "dot files"), and so on. Needlessly burdensome. Shared libraries are for the most part a "solution" to a nonproblem—memory is large and cheap to add.
3. Add a module assembler application and an associated configuration file. Now we're up to 3 + N (shared-object) files to install per host.
4. Make the configuration file XML. Now add the need for an XML parser (such as Expat). Overkill. 4 + N.
5. Make the configuration file a script program itself. Ugh. More logic to understand, test, debug, and so on. Add the interpreter (for example, Python) that the user must locate, download, install, and test on each platform and host. Oh, and hire a programmer fluent in that interpreted language, too. (Or users must become programmers.)
6. Finally, make the assembly process dynamic. Add requirements for a Web site connection, a service locator (remote Web services application, firewall modules), a database ("clearing house" or dumping ground for ever-changing, differently bugged implementations), and so on. Need help from system administrators now.
1. How does it help me configure the generic application system I've bought from supplier X? In my current work in healthcare systems, virtually all users are configuring systems, not developing them from scratch. I think this is also more broadly true of business systems. I have limited experience in this area, but the people I know are configuring SAP and Oracle systems.
2. How does it help me achieve my required levels of performance, availability, and reliability? The argument for MDA is that it's good for long-lifetime systems with changing platforms, but in my experience these systems' key requirements are performance and dependability.