I want to use an enum type to determine which equipment needs to be equipped on character creation. The only way I see to do it now would be a switch statement and create the right equipment in each case:

Would there be a way to get a class based off of the enum passed, so I would be able to make (clazz)Weapon1. That way I would only need one block of code for all of the character classes instead of one for each.

I'm not sure I understand what it is you are trying to accomplish here. Do you want things in an enum because you want all of the equipment code in one place? Here is a way to do it, although it doesn't use an Enum. (It uses static methods which some people don't like).

Then consider better organization of weapons and heads (inner classes perhaps) and whether you even need this method at all or could make them field defaults, and so on. But at least you'd have a start at putting it in the right place.

Wow, I just spent 10 minutes trying to explain what I wanted to do before I realized it would be waaaaay easier to put this stuff in each character class kind of like what sproingie suggested.

I still feel like I'll run into this issue at some point again (plus I'm really curious if its possible). So I'm going to try an articulate myself better this time.

So I have a class called WarriorWeapon1 and PriestWeapon1 that both extend Weapon. All level one weapons would be named in the same convention( <insert class name here>Weapon1 ). If I had a method called createWeapon(String className) how would you make it create the appropriate weapon? (I guess it doesn't have to be enum)

1 2 3 4 5

publicWeaponcreateWeapon(StringclassName){Stringtemp = className + "Weapon1";Weaponwpn = temp.createInstanceOf(); //this is obviously wrong, but can you use class loader or something?returnwpn;}

I've never used classLoader so I'm not even sure if that's what would be used. This is really hard to explain when I have no clue where to start coding this

Anyways, I know how to fix my original problem, but I still want to know if it's possible to do it that way because I think it would be useful. Hopefully that makes more sense because I don't know how to explain it better

I'm not sure about the wisdom of this pattern for specific domain classes like RPG objects, weapons and whatnot, it's really more suited for more abstract patterns. If you need to differentiate the behaviors of a sword vs a mace vs a halberd, you should look into composition before subclassing.

Ok, I understand better now what you are after I think. I have found myself in a similar situation where it felt like I was duplicating code. It was a similar case where I have a library of things and every time I add a new subtype, I also have to remember to create a new entry for the new thing.

I have issues with what you have because reflection is slow, using String keys makes things a pain, and you are relying on naming conventions. If you use an Enum, you are right back to where you started where you have to specify every item in the enum class. I also don't like reflection because it usually means more runtime errors that may have been compiler errors.

Having said all of that....one thing you could do to make it more palatable is to do all of your reflecting once up front, so you didn't need to do it every time you wanted to equip someone with something new. You could use the Reflections library to get a listing of all of the classes that subclass Weapon. You could then put a new instance of each class it into a Map where the key is the name. This would give you a library of "prototypes" that you could pull from. If you had an abstract getPrototype() method in the Weapon class each subclass could have code that would create a new "blank weapon" of that type. You could also override clone().

That all being said, I still don't like the approach and wouldn't use it. Another problem is what happens when you would like to pass in parameters at creation time? I knocked up in the browser window of how something like this might look....I am sure there are some mistakes. The code below could all be in a WeaponLibrary class. The only thing I really like about this is that you can create a new Weapon subclass and it will be made available here without having to also remember to add fields to enum classes or to if-then statements.

<CoverMyButt>I just did this as an exercise, I don't think I would use code like this...</CoverMyButt>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

// A map that holds a list of weapon prototypes, that will be indexed by their name.privateMap<String,Weapon> weaponPrototypes;

publicvoidinit() {

weaponPrototypes = newHashMap<String,Weapon>();

// Assume I have a list of all subclasses from the Reflections library.....I have no idea how it works.List<ClassSpec> weaponsClasses = Reflections.getSubClassesOf(Weapon.class);

// I am guessing that the Reflections library allows you to get an object that has information about the class.for (ClassSpecclassSpec : weaponsClasses) {// Use the prefix to access the name. (7 letters in Weapon1)// So WarriorWeapon1 should become WarriorStringweaponPrefix = classSpec.getName(0,classSpec.getName().length-7);// Add a new instance of the weapon class to the map.prototypes.put(weaponPrefix,classSpec.getClass().newInstance();}

// Returns a new copy of the prototype weapon based on its name.publicWeapongetWeapon(Stringweapon) {returnprototypes.get(weapon).getPrototype();}

Another way would be to allow the items to be copied.And then storing items in array based on enum.

As you will probably want to save and load the equipment. You can use it to copy items.All you will need to do is to add 1 function to the main item class that will take in item and return a copy of that item, by saving the item passed in to a buffer and then loading the new item from that buffer.

Another option is to pass the arguments to a constructor.(And if you're feeling lazy/have too many arguments create an enum of all the different types of that class and a utitilty/factory class which automatically fills in the data that is consistent throughout that type.)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org