Adaptive Object-Model

At first this was a difficult architectural pattern to understand because its' class definitions have a higher level of abstraction (e.g. Entity & EntityType). But after reading about the TypeObject pattern at http://www.comlab.ox.ac.uk/people/jeremy.gibbons/dpa/typeobject.pdf, the Property pattern at http://www.codeproject.com/KB/architecture/AOM_Property.aspx, and Entity Relationships at http://www.codeproject.com/KB/architecture/EntityRelationships.aspx, this made a lot more sense. My suggestion is for developers to get a good grasp on these patterns before they dive into trying to understand AOM.

The first thought that came to my mind was that AOM is pretty much database design. Its like the Entity class is a table that has a foreign key to the EntityType table. But this foreign key is actually a pointer to an instance (or typeObject) of the EntityType class. Data in databases are used by applications at run-time, which is analogous to meta-data being interpreted by AOM architectures. The only distinction the article gives is "The key problem with databases is attaching method to these objects". This leads me to conclude that the TypeObject pattern is more lot database design, but AOM includes interpreting and executing Behaviors and Business Rules.

I recently worked on a sub-system of an application that had the AOM architecture. All an administrator had to do was specify required fields in a form but when I looked at the code, I thought it was unnecessarily complicated. From the UI, it navigated through 3 classes where the implementation would read from the database to figure out what fields to display (e.g. Birth Time), how to display a required field (e.g. should it have an asterisk or a pound sign), and how to behave (Strategy Pattern. Should it throw an error message? If so, what message). The traditional way would've been to implement this statically as a class, but I soon realized how incredibly easy it was to update the form. All I had to do was add a new DB entry! We only provided the System Administrator limited ability to change the meta-data; more specifically, they had the power to change the required fields in a form. But we didn't want them to know that they could, theoretically, include new fields and change their behavior at run-time through simple DB modifications. Providing too much power to users brings the risk of them inadvertently putting the system in an unstable state. If they want a change in behavior, we can simply provide a DB-update script that would reflect the changes without having to recompile the code!