Custom modules on my armor; Best way of going about it

[Asweez]

So I have armor that will have different modules on it that do different things (i.e. underwater breathing or shooting arrows). What is the best way of 1) saving the modules to the armor and 2) making the modules take effect

 

1) What I have right now is and ID based system in which the armor saves the id of the module to NBT and then loads it back up whenever it needs to. Is this a good way of doing it or is there a better way?

 

2) How would I do this? Would I do a bunch of if statements?

For example

if(module1 is whatever){
     take effect
}
else if(module1 is something else){
     take effect
}

 

However this seems really inefficient. I could also make the Module have a method that enacts its ability, but there is a wide range of stuff the modules will do so it would have to have a few methods to encompass all of the times when it could be used. What is a better way to do this?

 

Thanks in advance!

[Asweez]

To 1 - That sounds fine. Depending on if you want to make this expandable by other mods you should consider using a String based ID instead of a numerical one (if you haven't already) to avoid the problems that e.g. ItemIDs have.

 

To 2 - The modular (he he) approach of having e.g. a "Module" interface with a bunch of hooks in it definitely sounds better. It allows for more readable and much less intertwined code (no "spaghetti code"). Of course you can only add so many hooks to that interface, but you should not need a crazy amount. And then you can always make an "Adapter" class, which is abstract and implements all methods in the Module interface with stub methods so that in the actual module implementation you only need to specify what you actually want to happen.

 

Thanks,

 

I'm a little confused on what you mean on number 2. So you're saying that the method within the module itself is the best way to do it? And what do you mean by an adapter class and how would I use it?

[Asweez]

~snip~

 

Ok just to make sure I know what you mean: the adapter basically removes the abstract methods you don't need. For example since ModuleFoo didn't need any update stuff, the adapter provided a stub method so ModuleFoo wouldn't have a blank onUpdate method. Is that right?

 

Anyways, thanks for that I'll definitely use that advice