[MUD-Dev] Object Models

[KevinL]

>>> Gavin Doughtie wrote
> I would attempt to assemble a composite object in this case, with some implementor
> of "edge", in turn containing a "material" property and methods like "sharpen" and
> "cut". The whole assemblage (combat stats, etc.) might live under a more generic
> "weapon" interface.
> 
> Seriously, you can go crazy with this stuff, but the whole point is to make things
> easier for the user (programmer, world builder) to understand. In real life you
> see much more "has a" than "is a subclass of" relationships among the objects you
> encounter. You also tend to solve problems by applying prebuilt components (i.e.,
> you don't manufacture your own drywall screws).

Yup, and I'm sold on components in cases like this.  I was just curious about 
that particular suggested way of tying things together - I can't help but 
wonder when I look at that whether things aren't being made more complex 
rather than less for the builders - especially if you introduce tight 
contracts into the mix, where you can't change a component without updating 
everything that uses it because the contracted interface has changed.

Regardless, here's the question:  You have a component that implements edge, 
material, maybe size, whatever.  You decide you need to modify the component's 
behaviour based on some aspect of the object it's being included into that 
you'd never considered - this runs close to some of JCL's previous posts about 
being able to affect the behaviour of an object under new conditions without 
having to recode that object.  Say, you've added the temperature of the object 
in question into the mix (heat it up, it's easier to sharpen, or something).

Do you now have to go back and re-make that component to accept temperature as 
an argument to sharpen, then modify every object using that component to pass 
the temperature in?  Or can you somehow make the component simply grab the 
temperature from the object it's been included into, thus dodging potentially 
large-scale changes?

This is my concern with components and contracts, at the end of the day - that 
they're good in a situation where you can nail down your requirements from the 
word go, but they're going to be a distraction where you want to be able to 
mutate things on the fly.  And (and I know this'll go down badly ;) I've never 
worked on a project that didn't mutate part-way through.  More, I'd suggest 
the places that encourage non-techs to build are the places where things can 
be wired together, and changed, with minimum fuss - on the fly.

Are there component systems around that don't implement the strict interface 
requirements John's argued for?

KevinL

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