[MUD-Dev] (no subject)

[John Buehler]

>From: "Joe Andrieu" <joe at andrieu.net>
>Date: Sun, 19 Nov 2000 22:17:10 -0800

>In comparing inheritance to components, what are the differences, if any,
>in memory usage and/or processing demands when your number of objects
>scales dramatically?
>
>I can see how components could be a good alternative to inheritance in some
>cases, but if I have tens or hundreds of thousands of objects (or more),
>each with potentially a dozen or so components, is that any worse or better
>than the same number of objects with an inheritance scheme?  Or am I
>misunderstanding the situation?

It's mostly a wash.  You're assuming that when a component is created, its
constructor is run and the instructions for creating the child components
are located there.  But it's perfectly reasonable for the structure of a
component to be captured at design-time.  Once the information is available
at design-time, it can be taken advantage of to make a single allocation for
all or some portion of the overall component.  This scales across multiple
levels of construction because it is collected at design time, when all
levels of involved components' information is accessible.

This capturing of component structure at design time was something that we
did.  We never got around to optimizing the creation process, but we were
looking at a variety of ways of taking advantage of the information,
including persistence.

Once you get both inheritance and composition approaches down to a single
allocation (ignoring secondary allocations made in the constructors or
during normal operation), the same number of constructors have to run and
it's essentially a wash.

Consider the real differences between the two approaches.

Inheritance:

1. All contributing classes are organized into a tree, and any class
contributes at most once to the actual class structure.

2. Contractual obligations between base and deriving classes are not
explicitly stated.

Components:

1. The structure of contributing classes is a graph, and any class can
contribute multiple instances to the actual class structure.

2. Contractual obligations between parents and children are explicitly
stated - using the same mechanism as between any other two components.  Note
that because a single mechanism is being used for both composition and
inter-component connections, and because all this information is available
at design time, it's possible to perform a single allocation to instantiate
an entire application.  Well, the static portion of it anyway.  In the case
of a language like C++, inheritance is used to describe class structures,
but there is no mechanism to statically describe application structures.

Typically, an inheritance tree structure is an all-or-nothing construction.
With components, you can either do an all-or-nothing construction or a
certain high-frequency portion of the functionality, and then construct
other pieces on demand.  Or mix and match for any other purpose.  There's
nothing saying that an inheritance system couldn't do the same thing, but
they 'typically' do not.

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev