views:

86

answers:

6

is it wasteful/bad design to use a vector/list where in most instances it will only have one element?

example:

class dragon
{
    ArrayList<head> = new ArrayList<head> Heads;
    tail Tail = new tail();
    body Body = new body();

    dragon()
    {
        theHead=new head();
        Heads.add(theHead);
    }

    void nod()
    {
        for (int i=0;i<Heads.size();i++)
        {
            heads.get(i).GoUpAndDown();
        }
    }
}

class firedragon extends dragon
{
}

class icedragon extends dragon
{
}

class lightningdragon extends dragon
{
}

// 10 other one-headed dragon declarations here


class hydra extends dragon
{
    hydra()
    {
        anotherHead=new head();
        for (int i=0;i<2;i++)
        {
            Heads.add(anotherHead);
        }
    }
}

class superhydra extends dragon
{
    superhydra()
    {
        anotherHead=new head();
        for (int i=0;i<4;i++)
        {
            Heads.add(anotherHead);
        }
    }
}

EDIT:(part 2 of the question)

Thanks for the replies. They have been very helpful. I've actually run into this situation more than once, and I'd like to give a second example that is unrelated to inheritance. This is actually a real-world example, and though I've decided my current project is small scale enough to be safe with using vectors based on your answers, it's a concept that I imagine I'll use on a much larger scale at some point.

In creating an engine for my current Android game project, I found it necessary to create an Imagepoint object that is basically a set of XY coordinates that are used to track significant parts of a sprite image. Say you have a bone character made up of several bitmaps, it's useful to know where the neck attaches to the torso, the forearm to the bicep, etc. This xy offset data is used later to calculate the position for various purposes, such as where to position other sprites by using trigonometric functions to find the xy offset given the current angle.

Most sprite objects will need only one image point. The bicep needs one for the forearm, the forearm needs one for the hand, the neck needs one for the head, etc. The torsos in my current character models are the exception, and they need several for the shoulders, the legs, the neck, and any removable decorative sprites.

The sprite is the object that contains the imagepoint vectors, there will be no inherited classes, because each : torso, leg, etc is simply an instance of the sprite class, which is strictly a graphical object, containing a pointer to the bitmap, these imagepoints, and assorted position/orientation data, and will not be used for any specialized purposes. If I were to use this concept on a large scale game with massive numbers of instances, where most would require only a single imagepoint, with a few objects requiring several or none, and where there would be no special cases meriting the use of inheritance. What would your thoughts be?

A: 

You could change the Head implementation to be a Composite type. That way, each extension of Dragon needs only one instance of Head and the Head takes care of GoUpAndDown().

Duracell
A: 

I would implement such features in deriving classes. To make this behaviour work, you have to be able to override methods (in your case, the nod() method). The baseclass shouldn't cater for all possibilities, it should present the base case, which can be extended. Just make the appropiate methods overrideable, so the deriving classes can implement the specific behaviour, and everything will work out fine.

Femaref
+1  A: 

I don't think there is a single answer to this question. It seems to me like it would be application dependent. If the application is a relatively lightweight dragon simulation that will never deal with more than a few thousand dragons at any one time, then it probably isn't a big deal to use a vector. If, though, it is a game involving millions of dragons, then it might make sense to optimize it slightly differently and maybe save a bit of memory and possibly shorten access time. But even that probably depends on the underlying class implementation. It is quite possible that the vector class you use could be optimized to handle a single element without extra overhead.

Mark Wilkins
+2  A: 

Yes and no.

I mean your question really depends on how are you going to use these objects.. personally I like to split behaviours and attributes as much as possible to "clusterize" them according to the kind of object they represent without caring about reusing some code a little bit less compared to a really inheritance approach like the one you proposed. Something like:

interface BigLizard
{
  void nod();
}

class Dragon implements BigLizard
{
  Head head;

  void nod() { head.upAndDown(); }
}

class ReallyScaryDragon extends Dragon { ... }

class Hydra implements BigLizard
{
  ArrayList<Head> heads;

  void nod() { for (Head h : heads) h.upAndDown(); }
}

And so on. This approach is like "having just exactly what you need for your objects without force anything to be a specific case". Of course this means that it will have two different implementations of nod() but when you don't need to optimize (and you should care about it only at the end) just stick with your personal preference, assuming that it doesn't go against any standard, widely accepted convention.

You don't have to make anything inherit from a single object, just customize the hierarchy as you like.. also a composite solution (like already suggested) would be a solution also if the concept of "head part" is not the same for your Dragon and for your Hydra..

A third solution for your specific case could be to use a LinkedList instead that an ArrayList. In this case whenever you have just one head you won't waste space (except for instantiation of the list) and you'll have just the next pointer of the head (of the list :D ) pointing nowhere.

Jack
+1  A: 

In this particular case, it'd probably be better to override nod() for your multi-headed dragons. Whether they have 1 head or 5 is a detail that really shouldn't be worried about in the base class (which should be as simple as you can reasonably make it).

You don't want to have to account for every possibility that every one of your code's users (even you) will ever need at every point in time. Otherwise, you'd need to account for 2-headed dogs (which are a lot more real than even 1-headed dragons). People extending your classes and such will be developers, too; let them do the work to account for the more exotic/bizarre cases, if they need to.

cHao
+2  A: 

If the head is publicly accessible, it'll need to be available as an array/list/collection so that consumers can deal with it.

Another way of dealing with this may be to switch to a more behavioral design rather than a stateful design. In other words, instead of having code telling the dragon to nod, have the dragon respond to an event that would cause him to nod, if that makes sense.

say("Dragon, would you like a yummy princess?");
if(dragon.Stomach.Contents.IsEmpty)
{
    dragon.Nod();
}

compared with:

say("Dragon, would you like a yummy princess?");
dragon.offerFood(princess);

// in dragon class
void offerFood(Food yummyFood)
{
   if(Stomach.Contents.Empty)
   {
        head.Nod(); // can be overridden by subclasses.
   }
}

In the second example, the consumer of the dragon class isn't asserting authority to make the dragon do things... all the consumer is doing is things (saying things, offering a princess) that he has the authority to do - the dragon gets to decide whether it wants to nod its head or not (which makes sense. I doubt that I'd be able to get a dragon to nod its head if it didn't want to!)

I call this 'behavioral' because the interfaces focus on the interactions between the objects (the dragon and whatever is offering the yummy princess) rather than the state of the dragon (its heads).

kyoryu