[MUD-Dev] (no subject)
joe at andrieu.net
Sun Nov 19 22:17:10 New Zealand Daylight Time 2000
> -----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)
> 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.
> 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
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?
joe at andrieu.net
+1 (925) 973-0765
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev