Solved Static minigame classes / Player objects in Lists

Hello folks,

i got two basic questions about plugin programming, especially for minigames.

1. Is it ok to declare a minigame class completely as static?
Because i will never go to have multiple instances of it, i thought in the past that it doesnt matter. Now i have over 10 minigames and im scared that it could affect the performance or something like that. In every game i got a method which empties all collections etc. at the end of the game.

2. Is it dangerous to use Player objects in Lists and other Collections, i.E. as a Hashtable key?
Should i use the playername instead? Ive seen some people doing this.

thanks very much!

 

@Lordloss
1. I'm not sure if it matters a lot, although instances are more reliable and recommended to use. If you have multiple minigames, I would prefer having an abstract class containing some basic minigame methods so you have easy control over more games.
2. It's not so dangerous, as long as you make sure you remove the players when they quit. If they do stay in the collection, it will cost a lot of memory because players hold lots of information that does not get out of memory.

 

Just a little extension to @megamichel 's comment:

You should not store the player objects, nir they names. Use the uuid-s, a player's name can change.

 

thanks a lot for your answers.
@mcdorli
but i think they cannot change their name while they are online, or? If they leave, they will be removed from the lists.

 

If it's only for temporary data, it's fine to use the player's name. However, if you are storing the data, then use the UUID.

 

It doesn't matter if you

Are you saying that you have 10 minigame instances? Just ask yourself this. Does this make sense from a OOP point of view?

 

@teej107 I think the OP means that he has 10 different minigames, not 10 instances of the same minigame.

 

@teej107
I like how you combined my sentence in yours ;3

 

No, under no circumstances is this acceptable programming practise.

What is acceptable in this case is a "Singleton" design pattern, in which the class has a static reference to its only instance and has a static getter method for its instance. This preserves encapsulation while allowing "static" access to the only instance of the class.

Ex.:

Code:

public class Singleton {
    private static Singleton instance;

    Singleton() {
        instance = this;
    }
  
    public static Singleton getInstance() {
        return instance;
    }
}

 

@teej107
I never have multiple instances of the same game, there area multiple different minigames i.E. spleef, runner, tetris, match 4, and many self invented ones... with very different structures. If there would be more than one instance of a game its obvious that static declaration is not suitable for this.

Thank you very much for your fast answers.