Active Object Model

See also AdaptiveObjectModel, which seems to be the preferred term.

One of the things about OOPSLA'97 that impressed me the most was that half of the demos had an explicit representation of their object model that they would interpret. Each system used a different name for this idea, often including "meta" as part of the name. But the name that I liked best was ActiveObjectModel.

[See MetaData, MetaLevel for more about "meta"]

You can easily get yourself in trouble with an ActiveObjectModel. It can make your application more abstract and harder for newcomers to understand. However, it can also drastically simplify an application, can make programs become much more extensible without recompiling them, and can make an expert extremely productive.

A system with an ActiveObjectModel has an explicit object model that it interprets at run-time. If you change the object model, the system changes its behavior. For example, a lot of workflow systems have an ActiveObjectModel. Objects have states and respond to events by changing state. The ActiveObjectModel defines the objects, their states, the events, and the conditions under which an object changes state. Suitably privileged people can change this object model "without programming". Or are they programming after all?

One of the systems at OOPSLA was used for defining potential products. The products were complex telecommunications equipment. Each product had hundreds of options, and only certainly combination of options were legal. The system had an object model that described the different components of a product and which configurations were legal. The whole system used only four or five classes, but these classes were things like Object and Relation. The thousands of kinds of products were all just instances of Object. They would configure a system for sale by making a clone of one of the existing Objects and customizing it. So, this system not only had an ActiveObjectModel, it used the Prototype pattern. The authors claimed they could build a system in .01% of the time that others took to build it.

The Hartford has an ActiveObjectModel for representing insurance policies. A policy is a tree of objects, each of which is an instance of Component. Each Component has a type, which is an instance of ComponentType?. Each instance of ComponentType? has a name and defines a set of attributes. For example, the ComponentType? named "Auto" defines attributes like "Make" and "Year", while the ComponentType? named "Property" defines attributes like "Address" and "Construction". The component representing the policy on a house has the type "Property", and gives values to all the attributes defined by the "Property" ComponentType?.

-RalphJohnson

This is similar to CustomizationViaProgramming.

Ralph, you mention attributes above, but what about methods? Moreover, is AOM really different from, say, a pure prototype system like Self?

It is very interesting to me that here the object model is made explicit and over in MultiCaster, the connection and notification models are made explicit. -- MichaelFeathers

This seems a bit related to BusinessRules, where the rules are made explicit.

I've seen systems that let you define rules and associate them with types. The Hartford system is one. But some of the systems don't do this, so it seems to be an optional part of the pattern.

Self is a language. These systems are not billed as languages, though of course you can think of them as languages. Self is prototype based, while these are based on the TypeObject pattern. JamesNoble has apparently seen quite a few prototype-based systems that are similar to this. I haven't.

A lot of patterns make something explicit that is usually implicit. I think that is a common trick in OO design.

-- RalphJohnson

Good insight. See also AspectOrientedProgramming. -- DaveHarris

I would have called it an AbstractMachine: you are building a custom set of entities and an instruction set to go along with it. All your domain problems are expressed as combinations of these things. I like these types of designs -- must be my Operating System bias. If you take this seriously, and take into account language-design issues like naming and scope and so on, the designs become super-flexible with little effort. A closely related idea is the Bell Labs' LittleLanguage school of design. Although I think the labs people were mistaken to build so many little languages, a single common language like lisp or smalltalk is much better. (Yes, I know they were working on resource-starved machines). -- AamodSane

Manufacturing systems (MRP, ERP) usually have more than one level of active models: one level often called Masters, e.g. Product Master, BillOfMaterial? Master, Routing Master, defines products and their associated processes generally. The Master level sometimes also has something corresponding to a TypeObject. In process industries, the Master level might be called Recipes or Formulas for products.

The next level is Planning or Specification, where people plan specific quantities of specific products to manufacture at specific times. This level is the ActiveObjectModel for the real-time event level. --Bob Haugen

See these pattern languages:

BrianFoote and JosephYoder, Metadata and Active Object-Models, http://www.joeyoder.com/papers/patterns/patterns.html

MartinFowler, Dealing with Properties, Copyright year 1997 http://www.martinfowler.com/apsupp/properties.pdf

In my experience, there is one element that makes an ActiveObjectModel work or break: If you can come up with a complete interpreter or not. The interpreter is actually the place where your domain knowledge goes in. It contains the invariants of the "BusinessRules", the fundamental rules the system has to play by. The system can not operate outside this invariants (unless someone comes up with a hack here and there). The variant parts (HotSpots) have been factored out to the object model it interprets.

It is interesting that the systems mentioned on this page are all dealing with a relative small and well defined ProblemDomain (Configuration: Combination allowed or not. Insurance: Case Insured or not). All problem domains where it seems to be possible to come up with a closed MetaModel of what is going on in the real word. So one prerequisite for succesfull applying the pattern might be to have

a relative small, well defined problem domain,
where all principal interactions and relations in the problem domain are known,
and where these can be abstracted into some kind of interpreter,
forming a FrameWork on a MetaLevel.

Regarding the last point: In my view, ActiveObjectModel is about creating a FrameWork, which is based on a higher problem domain abstration than usual (on the MetaLevel). Consequently, the flexible part of such a framework (the object model) operates on the problem domain level.

-- ThomasWeidenfeller

A note about the pattern's name. ActiveObject is a well known OO term, where it denotes that an object executes in its own thread of control. Maybe ActiveObjectModel is a misleading name?

Seconded! --PaulMorrison

CategoryPattern CategoryModels