Dynamic Object Model

DynamicObjectModel is an architectural style "discovered" by RalphJohnson around 1997. The application of this approach to SystemsDevelopment is more commonly known by the name of AdaptiveObjectModel.

The word "discovered" is used because in his paper, "Dynamic Object Model" at http://st-www.cs.uiuc.edu/users/johnson/papers/dom/DynamicObjectModel.pdf, Ralph referred to an earlier instance where another person named related work as a "Type Instance Pattern". Ralph himself had referred to this style as "User Defined Product architecture" before he published the above paper.

Some of the other points made in the paper include:

An implementation based on DynamicObjectModel is interpreted and this is one of the costs of flexibility of "dynamic objects". Dynamic objects provide a way of defining new types without additional programming. In a typical implementation "type defintions" are stored in databases so new types can be deployed by adding to this database.
The use of this architectural style has other costs such as the need to build "support facilities" for users of the resulting application. He suggests this is particularly important if the system is to be maintained by end-users and not system/application architects.

Other notes

I have located a SemanticWeb reference to this at http://www.w3.org/2001/sw/BestPractices/SE/ODSD/20051017/#ref-RTJ-2004

So I am hoping other WikiReaders may find this GangOfFour paper of interest.

-- DavidLiu Nov05

Does this material merit its own entry in the ProgrammingParadigm list? Or is it a category within ReflectiveProgramming?

Any relationship to TableOrientedProgramming? The paper mentioned a component called "StrategyPattern" that look like code / algorithm persisted in tables, in manners ?similar to TableOrientedProgramming

I have this pattern. I used it in 1994 to build an investor demo for Riverton Software, where the client needed to create and then instantiate new kinds of business objects and activities at runtime. Infinium Software, then known as "Software 2000", used this pattern to build "Infinium", a UI generation tool for their AS400 HR, GL, and other db products. I hadn't looked at it from the perspective Ralph describes - I always thought of it as turning the Smalltalk meta-structure crank one more time around. The use of a separate "Properties" object (generally a dictionary) has some very appealing characteristics, especially in a production environment. Dynamically-generated "member accessors" can, at least in Smalltalk, turn out to be much faster than you might think. As it turns out, these dictionaries can often be replaced by dynamically-generated Smalltalk classes without using the compiler. The trick is to recognize that ALL of their functionality will be accessor methods, and the resulting CompiledMethod?s can be copied from a single template; the required literals can be written in the literal frame by the generation method based on inspection of the slot name. As in many things, once you know what you want to do, and make it work, the performance optimization can then follow. -- TomStambaugh

Not to be confused with modern web browsers' DocumentObjectModel.

CategoryPattern