Adaptive-Model Architecture

The adaptive model system seems to be a great way to go if you're worried that the business logic of how objects interact will change frequently, but that the overall structure of the relations changes less quickly. This would allow the system to be updated frequently with new or revised rules on how objects interact without needing to take the system offline and without worrying that something has been missed (since the system is using rule objects we can alter those and know that they will be referenced). It seems both possible and necessary, then, that this model of software would allow its objects to dynamically change type. Since type is little more than a collection of properties and all of these properties have been abstracted out to a different object then reconfiguring to look at a new set or to slightly alter them should be a relatively simple process. It also makes sense to add this because if you're using a phone billing system like the one presented in the paper a misfiling that causes a landline account to be created instead of a cellphone account will have a lot of the same information: owner, number, billing address, etc. and so it should be simple for the user to go in and make the necessary adjustments without having to create a whole new entry in the system.

Calls become a bit more complicated, and for once I would have loved for the paper to delve further into the mechanics of the actual operation. However, we can say that since there is some base object type that decides at runtime what sort of object it is supposed to represent through the acquisition of meta-data direct method calls would only work if the architecture is strictly following the strategy pattern (which it should) so that we can be assured that the method calls are all consistently and appropriately named. Other options are also possible to ease the burden and allow for more flexibility, including storing the needed methods in the metadata itself.

The biggest concern for a system like this though, is the size of its object pool. After all, if you're allowing users of the system to generate their own objects it could very easily get into a situation where users are creating objects with only very small differences that should be handled in properties. The cure for this is two-fold: 1) limit the ability of the users to create new objects. By carefully constructing the UI for modifying the object set it should be possible to make it so that small differences naturally guide the user into simple creating a new instance of an already defined object, rather than a whole new object. 2) By ensuring training and having a maintenance staff. While not exciting, making sure that users are trained and are able to recognize when new objects are needed will go a long way to help contain the number naturally. And it should be not all that difficult as they are domain experts and so should have a solid grasp on what they are doing. A maintenance person may also be needed to ensure the continual and smooth operation of the system, and may be able to prune down some of the excess items.