java Constructor parameters

Started by
15 comments, last by Kk1496 9 years, 9 months ago

I am trying to create a text adventure in java. This is my first large program so, i may be going about it the wrong way. I planed to create a super class for generic items that parents sub classes for different types of items like health items and equipable items.

I have a basic class called item that has id, name, description, and weight variables. I have sub classes that add other attributes. do i need to include the super class's variables in the parameter for the subclass constructor? if not how would i set the super class's variables when I instantiate the subclass?

Advertisement

public class A {
   protected int x;
   public A(int x) { this.x = x; }
}

public class B extends A {
   private int y;
   public B(int x, int y) {
      super(x);
      this.y = y;
   }
}

If the base class doesn't have an empty constructor, then all the need items need to be given to the constructor when the object is created.

Having said that, you may be trying to create an object structure when you don't need one. You should favor composing items instead of inheriting. Large, deep inheritance trees, while neat from a computer science aspect, can become hard to manage.


public class A {
   private int x;
   public A(int x) {
      this.x = x;
   }
}

public class B {
   private int y;
   public B(int y) {
      this.y = y;
   }
}

public AB {
   private A;
   private B;
   public AB( A a, B b ) {
      this.a = a;
      this.b = b;
   }
}

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

@Glass_knife: so, if I continue with my inheritance craziness, I would have to feed a long list of args into the sub-class constructor and feed some of those into a super constructor.

Are you trying to say that instead I should just make different stand alone classes for each item? And, is this due to my level of experience with java or the scope of the project?

It's extremely common for Java programmers to overuse inheritance, even in the professional world. This is partly due to how it's taught, and partly due to the culture surrounding the language. No, I wouldn't make each item its own class. Remember that a class is a template for creating objects. Your individual items are objects, so just make them items. What kind of specialized behavior would you need an item subclass for in the first place? Consider that for a bit, and think about whether that behavior is really special to a certain set of things.

@SeraphLance: I guess what I meant was that I could make a class for all items with all possible attributes and make different constructors - picking and choosing which instance vars to use based on the type of item.

I would have to agree with Glass_Knife, you should favor composition over monolithic inheritance trees. Basically what that means is that an in game object(or entity) is made up of mutiple components. So for example if you had a Iron sword, it could have a wieldable component, a sword component, an iron component, it might even have a firey enchantment component.

You could code all of this into your game, but I'd suggest making it as data-driven as possible. So perhaps you could read from a text file or an XML file what each item is built of and your game would populate the world with those items. This is just a suggestion though, on smaller scale projects this may be overkill.

There's lots of good reading available on the topic of Entity-Component systems. There are a few articles on this site that go over how they work, a simple google search for "Entity-Component systems" should give you quite a bit to chew on for now.

Another good resource is the Artemis framework, so that might be something to look into(Although I'd say it's a bit beyond the scope of this project).


I would have to agree with Glass_Knife, you should favor composition over monolithic inheritance trees. Basically what that means is that an in game object(or entity) is made up of mutiple components. So for example if you had a Iron sword, it could have a wieldable component, a sword component, an iron component, it might even have a firey enchantment component.

This is another way to go. I'm actually not suggesting any design up front. Just code up what you need doing the simplest thing possible (i.e. no inheritance or composition or anything). When you find you keep writing the same stuff over and over again, refactor to common code. This may be a base class with child classes, or it may be objects composed of other objects.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532


I would have to agree with Glass_Knife, you should favor composition over monolithic inheritance trees. Basically what that means is that an in game object(or entity) is made up of mutiple components. So for example if you had a Iron sword, it could have a wieldable component, a sword component, an iron component, it might even have a firey enchantment component.

This is another way to go. I'm actually not suggesting any design up front. Just code up what you need doing the simplest thing possible (i.e. no inheritance or composition or anything). When you find you keep writing the same stuff over and over again, refactor to common code. This may be a base class with child classes, or it may be objects composed of other objects.

That's probably the best way to go, what I described may very well be overkill for this particular project. You should probably go with the simplest possible approach to get what you need to do done, there's no need to over complicate things.


When you find you keep writing the same stuff over and over again, refactor to common code. This may be a base class with child classes, or it may be objects composed of other objects.

that's what i was trying to avoid. I was trying to anticipate what I would need to re write.

I looked up "is - a" and "has a" relationships here:

It seems to me that Health item and equipable items could share common attributes so it "is a " type of item.

I was also thinking of making a large item class and picking and choosing which values to use in different constructors (not sure if i mentioned this before). Is this what some of you are talking about?


that's what i was trying to avoid. I was trying to anticipate what I would need to re write.

Number of times I have designed an API and had the end result match the design = 0.

As an example, let us say you have an Equipable base class, and then a HealthItem which "is a" Equipable item. Later you come up with different kinds of PowerUps, that aren't equipable but bestow some temporary benefit. Then you make a MagicBooster that "is a" PowerUp.

Months later you try to create a MegaHealthBooster, that is a HealthItem and is a MagicBooster. But now you have multiple inheritance, which is bad in C++ and not even allowed in many other languages. To get around this, you'll have to redesign your classes or create some silly hacks that will cause weird bugs down the line.

Just be aware that this will be an issue if you take the "BaseClass / ChildClass" design.

If you had game objects that are composed of other objects, then a MHB that contains a HealthItem and a MagicBooster is easier.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

This topic is closed to new replies.

Advertisement