On Adaptive Object-Model Architecture

The Adaptive Object-Model Architectural (AOM) Style provides an alternative to usual object-oriented design. While the traditional OOD generates classes with attributes and methods, for every business entity, AOM does not treat business entities as first class objects. Instead AOM represents classes, attributes, relationships and behavior as metadata. Every domain change that would otherwise, in OOD, require recompilation, can be performed by the actual user that can change the metadata. Furthermore, the metadata is interpreted at runtime, which means, if a business rule changed it is immediately reflected in the running application. Consequently the model is adaptable.

Transforming an OOD class hierarchy into an AOM one only makes sense when the behavior between subclasses that would represent business entities is very similar or can be broken out into separate objects. This usually reduces the number of classes in the object model and creates a class structure that does not change. Changing the spec of an AOM application usually means changing the content of the database where metadata is saved. So we can safely say that AOM, when applicable, reduces time-to-market by allowing users to experiment and provide feedback.

The adaptability of the system is implemented by means of a few design patterns as TypeObject, Properties, Composite and Strategy. Strategy and RuleObjects are usually used to specify naturally complex rules, while combinations, of rules (e.g. predicates and sets) are modeled through the Composite pattern. Metadata is usually read and interpreted first time when the object model is instantiated and also at runtime when the business rules should be applied. The easiest way to implement the metadata persistence model is by means of object oriented databases. However it is also possible to use a relational database model and even XML.

While very benefic for systems constantly changing, or for those that want to enable their users to dynamically configure and extend their system, the Adaptive Object Model has also disadvantages. Among these, the most important is the complexity of implementing such a system. Beside the several design patterns involved, the system should also provide new tools and GUIs for defining the objects in the system. Further complexity is added from having to implement the model interpreter and by the fact that two object systems coexist: the AOM model that is interpreted and the interpreter itself written in an object oriented programming language. Finally, since the tendency for an AOM is to lead to a domain specific language, all the problems associated with developing a language, such as providing debuggers, version control, etc., there will be extra burden for the AOM designer. On the performance side, as with every interpreter there are certain performance issues associated with AOMs.

Nevertheless, when applied correctly, AOMs are very interesting design models. While developers writing them have split opinions (with the ones understanding it, praising it, and the others claiming that it is too complex), the architects developing AOMs are usually very proud of them.