Question about superclasses. Pros and cons of an idea.

So I started working on a little RPG to help me learn more about java. Nothing to complex.

However I came across this program. I have a super class named TableList with two subclasses called Weapon and Item which also have subclasses.

Currently I have all the methods inside Weapon and Item, so whenever I try to call a certain method such as getName() on a TableList object the compiler tells me it can't find it.

What are the pros and cons of moving all of the methods to the TableList superclass and the pros and cons of casting my object to (Weapon) or (Item).

For moving the methods I see:
Pros: Not having to cast every time I need an object method called.
Cons: Every Weapon and Item will have the same methods, even though they shouldn't.

For casting I see:
Pros: Each object will still be specialized not sharing methods that they shouldn't have.
Cons: A lot of if statements to figure out what to cast the object too.

Any thoughts on this would be greatly appreciated.

I would suggest you use polymorphism. You can either make the super class TableList an abstract class and then have an abstract method for each method you want the subclasses to be capable of. If you need to instantiate instances of TableList you can give TableList a generic method which the subclasses override.

I don't know how I feel about downcasting the item because the testing would get a bit out of hand. If the superclass and the subclasses all have the same method, the compiler should be able to use the correct method.

Code:

---

class ABC{
  public void print(){
    System.out.println("Class ABC");
  }
}

class A extends ABC{
  public void print(){
    System.out.println("Class A");
  }
}
class B extends ABC{
  public void print(){
    System.out.println("Class B");
  }
}
public class C extends ABC{
  public void print(){
    System.out.println("Class C");
  }
  public static void main(String[] args){
    ABC x;
    A a = new A();
    B b = new B();
    C c = new C();
    x = a;
    x.print();
    x = b;
    x.print();
    x = c;
    x.print();
  }
}

---

Compile and run this snippet and observe the results. The super class ABC could also look like this

Code:

---

abstract class ABC{
  abstract void print();
}

---

Ok so you're suggesting that I take all the methods they all have but make them abstract methods and overwrite them at the weapon and item level?

I didn't really think about doing that, but it definitely seems better than what I was originally planning on doing.

So now I'm having this problem.

Code:

---

Exception in thread "main" java.lang.Error: Unresolved compilation problem:
The method print(boolean) in the type PrintStream is not applicable for the arguments (void)
at DropTest.main(DropTest.java:13)

---

This is line 13:

Code:

---

System.out.print(zomg.getName());

---

Ok, and here is the code:

Code:

---

import java.util.ArrayList;
public class DropTest
    public static void main(String[] args)
    {
          ArrayList<TableList> newDrop = new ArrayList<TableList>();
          newDrop.add(new Dagger());
          TableList zomg = RandomDrop.dropNewWeapon(newDrop);
          System.out.print(zomg.getName());
      }
}

---

Code:

---

public abstract class Weapon extends TableList
{
    private String name;
    public String getName()
    {
          return name;
      }
}

---

Code:

---

abstract public class TableList
{
    public abstract void getName();
}

---

Does anyone know whats the problem? I don't know how to fix this and google isn't really helping me right now.

Your getName method has a void return type. There is no print method that takes void as a parameter. Since you method is a get method does it not make sense for the method to actually return something?

Ouch, I feel retarded now. That's why I love this place, no where else do I voluntarily ask people to call me retarded.

Thanks very much junky. +rep.

Quote:

---

Originally Posted by Dark

I have a super class named TableList with two subclasses called Weapon and Item which also have subclasses.

---

Your statement semantically implies that a Weapon is a TableList; same with an Item. Is that true? If not, those two classes are not subclasses of the TableList class. Also google for Liskov Substitution Principle (LSP) which defines a nice test for classes being able to be a subclass of another class or not.

Don't just make a class a subclass of another class because you want to reuse (parts of) it implementation.

kind regards,

Jos

Yes I understand that, the name might not be within standards but the purpose it serves defines them as proper subclasses. They are both items, just one of them is equipable and the other is useable. I wasn't very inventive.

I believe TableList could alternatively be something like GenericItem. I also suspect this line will cause you problems

Code:

---

          TableList zomg = RandomDrop.dropNewWeapon(newDrop);

---

You can't instantiate an instance of an abstract class. You should try to abstract common methods into the abstract super class(in this case, TableList), and that should be the abstract super class. The subclasses can be abstract as well, however; I suspect you want to make them concrete classes(classes that can be instantiated).

Then can I suggest calling the parent Item, and rename the children as UseableItem and EquipableItem.

Indeed, since both of these work differently (one is for equipping your character, one is for using, whatever those terms might mean) that possibly they aren't as related as you may think.

Forgetting their properties (never a good way of deciding whether something is a subclass), what do these things do? If they don't do the same thing, that is a Weapon does not do the same thing as an Item, then they aren't related.

When I think of an RPG, I tend to think of a weapon, and a (lets say)health potion to be items. Different, perhaps, but a weapon is an item, as is a potion. If he does go ahead and make them distinct classes, how would you suggest he easily manage an inventory? You would want the inventory to contain types of both usable items(potions, food, etc), and equippable items(weapons, armor, etc). To me it seems natural to make them both come from a more abstract super class which contains the similarites(perhaps weight, price, etc). Then to simply manage an inventory of type SuperClass.

@Sunde that line works, I'm not instantiating an object just the reference. That's why it works. The line looks more or less like this after the RandomDrop.dropnewweapon(newDrop) goes down.

Code:

---

TableList zomg = new Dagger();

---

It just returns a randomly picked object that was added from a TableList array and sets zomg as the reference.

@Tolls, yes renaming everything would be a great idea and now that I solved my syntax errors I'm currently working out, on paper, how I want everything to be layed out. My preliminary sketch was incorrect and caused problems when I actually sat down and started coding.

This is the first real project I've worked on in Java so without any guidance its a learning experience. Think as Weapon as a dagger in an rpg and an item as a health potion for example. They are similiar in every way except for how they are used by the hero.

However if you have an alternative to how they are stored in an inventory, dropped by units and classified I am all ears. This seems logical to me, however I have been proven wrong before.

EDIT: I guess Sunde formulated his thoughts faster than I. Too slow.

Oops, for some reason I thought dagger was a weapon. Sorry for the confusion.

The breakdown goes

TableList -> Weapon -> Dagger

So yes a Dagger is a Weapon, but also a TableList. Transitive property is how it was explained in Head First Java.

OK.
I was merely going on the description above about Useable and Equippable.
Those imply two separate interfaces.
Some things are Useable (a potion), some are Equippable (armour), and some are both (a sword).
A Useable thing can either be used on your self (useOn(Player player)) or on some other thing (useOn(BadGuy badguy), useOn(Scenery scenery)). An Equippable thing can simply be stuck on the character (equip(Player player)), though maybe that should be on the character class...I am making this up as I go along...:)

You'd still have the parent Item abstract class, which you use for your Inventory.

Does that make any sense?

I'm a little confused as to where you're going with that idea. I understand what you mean by there isn't really a defined line between items, but remember this is a simple 2d rpg that is not going to accomplish anything other than some random events and moving around a grid.

Every developer has to define what is what in their RPG some way, and for this one in particular I feel like my method will suit everything I need at this time. However I am open for suggestions, only a fool would deny council after asking for it.

Right now the only plan for my RPG is to have a hero walk around a grid, random creatures pop up, you fight, the end. Maybe later I'll expand on it, but I doubt it. I have two super classes right now, TableList for weapons/items and Unit for Heros/Enemies. If you see something that may turn out to be a critical error in the future I would appreciate feedback, especially since the majority of people here answering questions are established programmers and have more experience than I.

And I was making suggestions based on the fairly thin requirements in this thread.
I was using what I know of RPGs to put forward a structure that I thought might help.

RPGs usually have equipment slots, so weapons and armour and certain other items (rings etc) can be equipped. Think Baldurs Gate, or even Bards Tale. There are also things you can Use. Not all things you can Use can be Equipped and vice versa, hence my breakdown of the model into two separate interfaces.

So, you have an Item class (essentially your TableList), and subclasses of that that implement one or both of Useable and Equippable interfaces. So Weapon implements (in my mind) both. You can, of course, simply choose to have a Weapon implement Equippable, and the code for fighting simply check which Weapon is Equipped.

But if you make the split now then, should you decide to make the game more detailed, you'll have the building block in place.

That's where I'm coming from.

Ok I see your point. I like the idea, but I don't think that much detail is really necessary at this point. It may be a little clunkier than your method, but having an reference in the hero class to tell me which object is equipped seems like it will be easier and suit my purpose just fine.

I do have something similiar though, TableList is basically my item class, and weapon is my equippable with my item being useable. Its a little weird right now because of the names, but I think we have a similiar thought process in mind. When I first created Weapon I was considering only putting weapons in it, but a better super class would indeed be equippable items.

This project is just for learning in my eyes, like when someone recreates windows calculator or notepad. Its not because you're trying to sell it to get rich, its just a learning project to keep you focused. I don't feel I'm learning much if I don't see some reward and thus it discourages me from sitting down and devoting a chunk of time to learning. The reward in this case is seeing that I'm actually capable of making something simple, but yet not a copy paste code project from a book.

I hope you didn't take anything I said to be offensive, because honestly even though its just a discussion it really helps roll things through my head. Taking a second look at it, I think our main idea about the split are essentially the same. Our method of completion might differ though.

Here's another question, I'm thinking about putting certain methods in the TableList class. IE getName(), because not only do Weapons have that method, but items will too. Does anyone know any reason why I shouldn't do this?

That's perfectly reasonable, presuming they all do the same thing.