[cap-talk] "Composite", was "Same" key

[David Hopwood]

James A. Donald wrote:
>     --
> David Hopwood:
>> >  - use "object", and accept that this is
>> >  inconsistent with the majority of current and
>> >  historical usage in object-based systems, going
>> >  back to 1965.
> 
> Toby Murray wrote:
>> I've been following this discussion but can't remember
>> seeing anything about object meaning >=1 atomic
>> objects being inconsistent with historical and current
>> usage in object-based systems. Sorry if I'm asking for
>> evidence that has already been presented, but could
>> you give some examples?
> 
> Google, and you will find people continually using the
> word "object" to refer to both atomic objects, and to an
> object that returns references to some of its interior
> objects.
> <http://www.google.com/search?q=pattern+aggregate+object>.

Reading the first ten linked pages, I see nothing to support this assertion.
Instead I see that the "GoF" patterns book:

  Design Patterns: Elements of Reusable Object-Oriented Software
  (Addison-Wesley Professional Computing Series), 1995
  Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
  ISBN 0201633612 or 978-0201633610

is very influential, and that its usage of *several different* terms for
composites has been slavishly copied in numerous places:


<http://en.wikipedia.org/wiki/Design_Patterns> contains no uses of "object"
to refer to composites. The word "components" is used once, possibly in that
sense. It also has the following slightly confused sentence:

# The authors further distinguish between 'aggregation', where one object
# 'has' or 'is part of' another object (object orienteed [sic]) (implying that
# an aggregate object and its owner have identical lifetimes) and acquaintance,
# where one object merely 'knows of' another object.

in which "aggregate object" is being used in the sense of an object that
refers to another object with the same lifetime. The composite in this case
would be made up of *both* objects.

<http://en.wikipedia.org/wiki/Aggregate_pattern> contains no uses of "object"
to refer to the aggregate. It does contain uses of "object" to refer to the
main facet of the aggregate (e.g. "Create an object as a wrapper..."); on
careful reading, these definitely do not refer to the aggregate as a whole.
The pattern as described only seems to cover composites with one main facet.

<http://home.earthlink.net/~huston2/dp/iterator.html> does use "aggregate object"
in the sense of "composite", in the context of the Iterator pattern. However, it
never uses "object" alone in that sense.

<http://www.dofactory.com/Patterns/PatternIterator.aspx>: same comment as previous.

<http://www.answers.com/topic/aggregate-pattern> is a Wikipedia mirror.

<http://www.ericfeminella.com/blog/as3-model-view-controller-implementation/> is
a description of MVC that only uses "object" to refer to individual objects (e.g.
the Model, View and Controller facets). It uses "aggregate object" to refer to
a collection composite, again only in the context of the GoF Iterator pattern.

<http://websphere.sys-con.com/read/43302.htm> is talking about the
"Aggregate Entity" pattern. Apparently this is a variant of the Aggregate
pattern mentioned above, but using the term "aggregate entity" instead of
"aggregate object". I wonder why they did that? :-)
(OK, one reason is possibly that "Entity" means something specific in the
context of "Entity Java Beans". A "bean" is also a composite.)

<http://wiki.cs.uiuc.edu/PatternStories/DesignPatternsReferenceCard> is a summary
of design patterns, apparently all quoted from the GoF book. None of these summaries
appear to use "object" in the sense of a composite (they're very short, so it's a
bit difficult to tell).

Interestingly,
 - the description of "Bridge pattern" uses "abstraction" in my sense.
 - the description of "Composite pattern" uses "composite" in MarkM's sense:

   # Intent: Compose objects into tree structures that represent whole-part
   # hierarchies. Composite lets clients treat individual objects and compositions
   # of objects uniformly. A leaf has the same interface as a node.

 - the description of "Facade pattern" uses "subsystem" for the same concept.
 - the description of "Visitor pattern" uses "object structure"; it isn't clear
   whether this is necessarily a composite, but it might be.

<http://www.cs.wustl.edu/~schmidt/PDF/pattern-examples4.pdf> again quotes the GoF
summaries (using "subsystem" in Facade pattern and "aggregate object" in Iterator).

<http://www.teknirvana.com/internal_documents/Patterns.pdf> uses "component" in
the sense of a composite when describing the Decorator pattern; otherwise it is
another retread of the GoF book.


So we appear to have one (admittedly very influential and widely quoted) book that
uses "aggregate object" to mean a composite, but *also* uses several other terms
to mean a composite, including "abstraction" and "composite" itself. Consistent
with my argument, it does not use "object" alone to mean a composite.

*If* we were going to use a variant of "aggregate object", then plain "aggregate"
would be more concise, and wouldn't be subject to the objection that it is mixing
up two levels of abstraction. However, I don't see that this would avoid the
criticisms that have been levelled at "composite": it isn't very intuitive that
an "aggregate" can be implemented by a single object, or that an interface-
subsetting wrapper is constructed by aggregation.

> David Hopwood's usage is new, unusual, non standard, and
> not English.
> 
> The standard and long established usage is that an
> aggregate object is an object that exposes references to
> some of its interior objects, and an atomic object is an
> object does not - but both of them are objects.

"Aggregate object" appears to be a fixed expression from a single source. I didn't
see any evidence in the above pages that "aggregate" was being used as a simple
predicate referring to some subset of "objects". It is quite often the case that
a technical term of the form "adjective noun" does *not* simply refer to the set
{x:<noun> | x is <adjective>}.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>