Possible to make an enum of anonymous inner classes?

[Roquen]

Well at least you get it... but the whole point of this was I don't want to have to create 20 different classes for 20 different weapon types. Meanwhile, everyone else still thinks I mean I want different parameters to define damage, speed, etc...

I understand exactly what you're saying, except perhaps the "scale" of different behaviors.  The "scale" does have an effect in terms of a reasonable abstraction vs. engineering time.

You don't have to create 20 different classes - you only create a NEW CLASS when you need BEHAVIOUR that is different.

Exactly...you only need a new class when a behavior cannot (or isn't worth) making data-driven.

.. BEHAVIOUR wouldn't they. But your data would be different - that is the point.

Again, exactly data-driven design is your friend.

I already know HOW to make an anonymous inner class to implement the weapons the way I want... the only reason I asked this was to determine if I could somehow put the declarations for these in a separate file and be able to just import them and use an ID to refer to the object without cluttering up my main code.

With no notion of scale this is a difficult question to answer...and most likely few of us would agree on what the cleanest solution is.

[Icecore]

without cluttering up my main code.

/*****************/
File 1 – bullets :
Arraylist list
Bullet 1 – id 1
Bullet 2 – id 2

get_By_ID(int id_Find){
 for Arraylist
   Object obj = list.get(i)
   if(id_Find == obj.id)
        return obj
}
get_By_Name(String name_Find)
      if(name.equals(name_Find)) //Not lf(name == name_Find) Dont do that // Obj == obj - memory address !!!!!
//...
/*****************/
File 2 – Graphicks :
//...

/*****************/
File 3 - weapon
new Weapon(1, 15); //Weapon bullet - id 1, Graphicks  Id -15
new Weapon("Pistol_1", "Pistol_2"); //Weapon bullet Name - Pistol_1, Graphicks Name - Pistol_2

[packetpirate]

I'm going to make one last attempt to get my point across in case anyone is still confused. I wrote a prototype Weapon class similar to what I was looking for. Instead of using an enum, I made a class called "WeaponType" with public members containing the anonymous inner class objects. Note that what the fire() method does in this example is irrelevant. It's to demonstrate what I meant.

Main Class: http://pastebin.com/MYewSQgv
Weapon Class: http://pastebin.com/kAJrpVGL
Weapon Interface: http://pastebin.com/MQyv1nzC
Weapon Type Class (Contains anonymous inner classes): http://pastebin.com/QbFuLyMy

I hope I got the point across this time.

Games published by our own members! Check 'em out!

[saifix]

I'm going to make one last attempt to get my point across in case anyone is still confused. I wrote a prototype Weapon class similar to what I was looking for. Instead of using an enum, I made a class called "WeaponType" with public members containing the anonymous inner class objects. Note that what the fire() method does in this example is irrelevant. It's to demonstrate what I meant.

Main Class: http://pastebin.com/MYewSQgv
Weapon Class: http://pastebin.com/kAJrpVGL
Weapon Interface: http://pastebin.com/MQyv1nzC
Weapon Type Class (Contains anonymous inner classes): http://pastebin.com/QbFuLyMy

I hope I got the point across this time.

You can do this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

enum WeaponType {     FLAMETHROWER(...) {         void fire(Point2D target) {}     },         PISTOL(...) {         void fire(Point2D target) {}     };     private WeaponType(...) {}         abstract void fire(Point2D target); }

[Jimmt]

@Icecore
I would recommend using a code tag if you really don't want to avoid clutter.

[sproingie]

You're still creating a new subclass for every type of weapon you define, you've just stripped them of meaningful names -- they'll show up in tracebacks and toString and so on as WeaponType$1 and WeaponType$2 instead of Pistol and Flamethrower.  I just don't see what that buys you.  Wanting to avoid lots of subclasses is a laudable goal, but you're not going to get there by making them anonymous, you only really get it through composition of traits.

You could also use the enum syntax sugar described above, where you will at least get meaningful names, but that does statically restrict your set of weapons at compile-time -- that's kind of the point of enums in general.  So enums also won't really buy you anything.

It sounds to me like maybe you want to be able to introduce new weapons on a "plug-in" basis by having different jars declare "here are my implementations of WeaponInterface".  For that, you've got SPI, but that's a whole new rabbit hole which isn't worth going down here, unless I know that's exactly what you want to do.

[ctomni231]

I read this entire thread, and I must say that what you are trying to achieve with enums is very wasteful. Chances are that the weapons list is going to grow, and some weapons are going to share types and firing patterns.

Eventually, you are going to have to code each type of firing pattern and weapon behavior in the game. Wouldn't a better solution be to make a WeaponPattern and WeaponBehavior subset? Then a generic Weapon class that uses those 2 features can be created.

You can only have so many Weapon Behaviors and Firing Patterns. So instead of focusing on the weapon enumerations, you can instead focus on the Behaviors and Pattern. If each weapon can only have 1 firing pattern and 1 behavior, you should be able to dramatically reduce the amount of classes you need.

1   2   3   4   5   6   7   8   9   10   11   12   13   14

public class Weapon(){         private String weaponName;         private WeaponBehavior behavior;         private WeaponPattern pattern;         Weapon(String name, WeaponBehavior behavior, WeaponPattern pattern){                //Initialize weapon here        }         public void fire(){                //This weapon fires        } }

Since your beginning goal was to not use a different class for each weapon, you can use one Weapon class to determine the firing pattern and behavior for all weapons. Enumerations will just have you write a lot of extra code regardless, and all you'll achieve is a Weapon ID.

[Roquen]

As a sanity check note that all of this is an utter waste of time if your number of weapons is small.  Just make a single class per weapon and move on to the next thing.  Otherwise all the the useful comments are saying the exact same thing and are simply using different constructions and different levels of data segregation.  Be data-driven and use composition.