[MUD-Dev] (no subject)

[Joe Andrieu]

> -----Original Message-----
> From: mud-dev-admin at kanga.nu [mailto:mud-dev-admin at kanga.nu]On Behalf Of
> John Buehler
> Sent: Sunday, November 19, 2000 8:32 PM
> To: MUD-Dev
> Subject: Re: [MUD-Dev] (no subject)
>

[snip]

> Whenever you think inheritance, think composition instead.  What
> if, instead
> of inheriting some chunk of functionality, you built it into a
> self-contained service component that provided the same
> functionality?  That
> service component now has to have clearly-defined behavior that
> anyone can
> reuse.  Further, you can use that service component multiple times in the
> same component for different purposes.  That is, you can create multiple
> copies of it for your different purposes.

[snip]

> Think of implementation inheritance as a poor-man's component system.
> Inheritance systems tend to have a fairly compact notation for the
> compositions, and they are accomplished by 'inheriting' implementations.
> But that's what a component is - an implementation (of a
> specific behavior).
> Your comment about added complexity is off the mark, I believe.
> If I give
> you a component language and some starting components, you'll be
> like a kid
> in a candy store.  Or perhaps I should say: a kid in a lego store  :)

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?

-j

--
Joe Andrieu
Realtime Drama

joe at andrieu.net
+1 (925) 973-0765


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