A nice pattern

I'm happy to find it on the web
for this is a nice pattern that is the first level towards metamodeling.

http://www.ksc.com/article3.htm

(as an old CLOS Moper I do not like the aka MetaObject because the  
typeObject is not really that
but this is a really cool and important pattern).

Stef

Hi Stef,

this pattern is bread and butter in practice, what is it that you find so  
important about it (perhaps besides that is gets a new name every now and  
then ;-)

You work in a Department which has a Location in a Building. All these  
departments belong to the same University which has Location  
(superlocation of the departments' location) and Web site (superpage of  
the departments' Web pages). Et cetera. Of course the Movie / VideoTape  
example is nicer, even kids would understand it when "tape" would be  
replaced by "game" 8-)

Students of database normalization even (hopefully :) know the value i of  
the pattern's corresponding i-th normal form. In its most general form,  
the pattern is B.O.M. (a pre-computer age name for it), see 4th entry on

- http://en.wikipedia.org/wiki/BOM

and it is indispensable in the construction business (yeah, also in the  
software construction business :)

But it also has drawbacks: say you have a B.O.M. for the A380 monster and  
you ask, how many of the constituent parts do we have to purchase for  
assembling one instance of that beast. Then you will see, that "S" in SQL  
stands for "simple", because SQL alone cannot explode a B.O.M. (regardless  
of how you design the corresponding database): the system (a data  
language) MUST be extended (i.e. by a computer language) for to obtain  
that solution (OT: has some form of G"odel's incompleteness).

And large B.O.M's are typically maintained by many people (in a  
collaborative fashion, like Squeak source code) and time dictates that  
they are often inconsistent. IMHO they are the "mother" of inconsistent  
designs (sw, hw, etc) in the construction business.

/Klaus

On Sun, 20 Aug 2006 21:02:26 +0200, Stéphane Ducasse wrote:

On 21 août 06, at 10:00, Klaus D. Witzel wrote:

> Hi Stef,
>
> this pattern is bread and butter in practice, what is it that you  
> find so important about it (perhaps besides that is gets a new name  
> every now and then ;-)

Because a good pattern is about simple practice and important ones.

Stéphane Ducasse wrote:
> I'm happy to find it on the web
> for this is a nice pattern that is the first level towards metamodeling.
>
> http://www.ksc.com/article3.htm
>
> (as an old CLOS Moper I do not like the aka MetaObject because the  
> typeObject is not really that
> but this is a really cool and important pattern).

I've got a better one:

The Aggregator pattern
by Michael van der Gulik

Intent

This pattern allows the programmer to associate many different instances
of one class with a number of other instances of that same class. This
allows the programmer, using only a single reference, to locate any of
the instances of those classes within the grouping.

Also Known As

PowerBag[EeL93], OrderedCollection[ToAd94], BetaSet[fiSH98].

Motivation

Sometimes the complexity of a system requires that many objects of the
same class need to be aggregated into the same location of the system.
The programmer often needs to locate instances of unknown classes in the
system depending on some common attribute of the instance's type.

Consider, for example, a system for tracking the videotapes in a video
rental store's inventory. The system would obviously require a class
called "Videotape." Each instance of Videotape would represent one of
the videotapes in the store's inventory.

However, since many of the videotapes are very similar, it will be
difficult to locate different instances of Videotape. Many copies of The
Terminator would stored in the same general location as copies of Star Wars.

One way to solve this problem is to have a lot of instance variables,
each pointing to a unique instance of Videotape. Thus, there would be
separate instance variables pointing to "Star Wars" and "The
Terminator". In order to keep the system flexible, the programmer would
also need to create a number of spare instance variables for future use.

This solution works, but not very well. If the programmer wants to add
another tape, such as "Bambi", and the pool of instance variables is
depleted, then the programmer will need to add new instance variables
and recompile the program.

Instead, since the number of instances of VideoTape is unknown
beforehand, an Aggregator pattern could be used. The aggregator is a
single reference to a complex data structure, which can hold any number
of instances of VideoTape:

Aggregator ---* Videotape
             |
             +-* Videotape

This class diagram illustrates how a single Aggregator pattern can hold
any number of Videotapes, where the number of Videotapes is not known at
compile time. The "has a reference to"-relationship between the
Aggregator reference and the Videotapes is an example of an Aggregator
pattern.

--

I could go on, but I run the risk of having my work referenced by other
academic papers...

Michael.

A BOM is not Type Object.   The point of Type Object is that the
"type" describes a general category or "type" to which the instance
belongs.  A BOM describes a part-whole relationship.  An instance is
not a part of the type.  A BOM is like Type Object in that there is a
1-N relationship, but otherwise they are different.  If the Type
Object pattern makes it possible to make that misunderstanding then it
is poorly written.

The Aggregator pattern should be called "Collection", and it is very
important to teach it to new programmers.  It is not worth putting in
a more advanced book of patterns because everybody knows it already.
On the other hand, a lot of programmers don't know Type Object.
Smalltalk programmers usually do know it, though, because we think of
classes as objects and so it is easy to imagine that we have a
class-like object that is not a class, but is just a regular object.
When I use Type Object in Smalltalk, I like to give the type a #new
method to create an instance of that type.  This helps convince people
that it is a little like a class.  But even among Smalltalkers, it is
useful to have a name for the pattern.  I've helped several projects
by naming the pattern that they were already using and thereby helping
the architect (who already understood the pattern deeply and
intuitively) communicate with his team.

-Ralph Johnson

On 21 août 06, at 14:26, Ralph Johnson wrote:

> A BOM is not Type Object.   The point of Type Object is that the
> "type" describes a general category or "type" to which the instance
> belongs.

Yes

Before knowing TypeObject I was developing an application to manage  
my cactus collection
and there you want to make the distinction between the plant that you  
hold in your hand
and that got a insect attack and made 3 times flowers from the  
general gender, family... location...
book ref. You want to have your concrete object and a "type"  
descriptor object that you can share
between all the plants of the same kind. And I read TypeObject and I  
said ok this is it.
I implemented without knowing it so this is the proof to me that this  
is a really cool pattern.

Yes.
One pattern that always worried me is chain of responsibility since
we cannot really use the name for classes.
I was discussing that with avi since in seaside the decorator are in  
fact
chain of responsibility.

:)

>
> -Ralph Johnson
>

Hi Ralph,

on Mon, 21 Aug 2006 14:26:13 +0200, you wrote:

> A BOM is not Type Object.

Not that I wrote that, I wrote: "... most general form ...", which can be  
read as: class "Type Object" inherits from B.O.M. :)

> The point of Type Object is that the
> "type" describes a general category or "type" to which the instance
> belongs.

Sorry, I do not read this kind of magic in the words "Type Object". It can  
be used the way you described, no problem.

> A BOM describes a part-whole relationship. An instance is
> not a part of the type.

Sure, constituents are part of the whole. And instances of your "Type  
Objects" are part of your "instance" objects. Because of N:1, the opposite  
direction would not be possible.

> When I use Type Object in Smalltalk, I like to give the type a #new
> method to create an instance of that type.

You mean like #newTypeObject?

> This helps convince people
> that it is a little like a class.

And I would teach them that #new is inherited from the instance side of  
Behavior and why this is so and what #new is good for in Smalltalk (and  
copycats) and then let them find out that #new is based upon a primitive  
which cannot be overridden.

> But even among Smalltalkers, it is
> useful to have a name for the pattern.

Absolutely. And I agree with you that Type Object is a nice pattern and a  
nice name. My question for Stef was rather about, what is the importance  
of this (almost) unavoidable pattern (which I attempted to generalize a  
bit further) and which he put at the first level towards metamodeling (as  
if metamodeling where a hierachical concept with root "Type Object").

> I've helped several projects
> by naming the pattern that they were already using and thereby helping
> the architect (who already understood the pattern deeply and
> intuitively) communicate with his team.

Yes, communication is good and even better if people mutually understand  
the respective vocabulary.

/Klaus

> -Ralph Johnson
>
>