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
. 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.
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
The Hartford has an ActiveObjectModel
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?
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
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.
Good insight. See also AspectOrientedProgramming
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:
, Metadata and Active Object-Models
, 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 (HotSpot
s) 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.
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?
See also: http://www.adaptiveobjectmodel.com/