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
See also:
http://www.adaptiveobjectmodel.com/
CategoryPattern CategoryModels