Re: Re[4]: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 22:24:23 +0000, Jake Staines <ja...@bi...> wrote:
> Well, you seem to suggest more or less exactly the same thing, only at
> a 'vehicle' level instead of a 'part' level; that there should be a
> 'GetTV' method at the topmost node that calculates its own TV then
> calls 'GetTV' on each of its component vehicles or sections. Same
> idea, we're just proposing using the same ultimate base class for
> systems as well at the very least. I'd be tempted to call the
> 'collection of perks' part a Part, as well, for instance, since
> essentially IIRC it just counts how many items it has (with a couple
> of special cases, true) and returns that as a single value.

True, but I think breaking things down that way at the level of
individual sections hurts more than it helps. Individual sections have
a very definite and regular structure, one that we can take advantage
of to make our lives easier by avoiding unnecessary levels of
containment. (Which we then have to manage in code) Once you get into
aggregations of sections, you unavoidably introduce complexity.

Though right now, few designs really take advantage of it, because
it's a pain to deal with. Perhaps, considering the horrors we might
unleash if vehicle designers can use transforming combining
multi-section vehicles at whim, this project is a bad idea. ;)

> Well, they kind of have something in common, in that they all have an
> impact on the final total TV. How you go about slicing them up
> class-wise depends on how you plan to go about calculating the TV (or
> vice versa), I suspect.

Very true. I just want to do so using the simplest possible method.

-- 
-Nick Pilon