2

I haven't found a good answer to my question regarding the best way of handling multiple objects in Java. I have seen a couple of questions here on StackOverflow, but I'm not satisfied with the answers that they have.

Let's say I have a Player class:

public class Player
{
    private String nickname;
    private long maxHealth;
    private long health;

    public Player(String nickname, long maxHealth, long health)
    {
        this.nickname = nickname;
        this.maxHealth = maxHealth;
        this.health = health;
    }

    public String getNickname()
    {
        return nickname;
    }

    public void setNickname(String nickname)
    {
        this.nickname = nickname;
    }

    public long getMaxHealth()
    {
        return maxHealth;
    }

    public void setMaxHealth(long maxHealth)
    {
        this.maxHealth = maxHealth;
    }

    public long getHealth()
    {
        return health;
    }

    public void setHealth(long health)
    {
        this.health = health;
    }
}

Let's also say I have a game where there are multiple players in one game, depending on how many users are online. It would be necessary to store all the players somewhere, we want the information like health to be saved and retrieved later on, changed and saved again. With my current knowledge I would create something like this to do the job:

public class PlayerManager
{
    private static final PlayerManager SINGLETON = new PlayerManager();
    private final Set<Player> players;

    private PlayerManager() {
        this.players = new HashSet<>();
    }

    public static PlayerManager getSingleton()
    {
        return SINGLETON;
    }

    public void addPlayer(Player p)
    {
        players.add(p);
    }

    public void removePlayer(Player p)
    {
        players.remove(p);
    }

    public boolean exists(String nickname)
    {
        return players.stream().filter(p ->  p.getNickname().equalsIgnoreCase(nickname)).count() == 1;
    }

    ... getPlayer(String nickname), ... 
}

My whole project would be able to use the PlayerManager singleton to add, remove and retrieve players. It would work, but I have the feeling that this is not the best way of doing this. What is the best way to store and retrieve objects?

Kedar Mhaswade
  • 4,535
  • 2
  • 25
  • 34
Wout_
  • 21
  • 4
  • 5
    I'm voting to close this question as off-topic because It is about working code and should ask at http://codereview.stackexchange.com – Jens Mar 11 '16 at 17:47
  • This is a good approach, but you **should use** a [synchronize object.](http://stackoverflow.com/questions/3047564/java-synchronized-method-lock-on-object-or-method) – Victor Mar 11 '16 at 17:48
  • I understand the need of using that if I would have multiple threads accessing the objects. But do you really think my approach is a good practise? – Wout_ Mar 11 '16 at 17:52
  • If you have a Game class, why not store the players there? – Stefan Haustein Mar 11 '16 at 17:54
  • Wouldn't that be a step towards an God class? – Wout_ Mar 11 '16 at 17:54
  • Global state should be avoided. Does your entire program really need access to PlayerManager? If so, there's a good chance you have some speghetti code conjuring. Instead, you should be using dependency injection to pass the `PlayerManager` only to objects that require it. – Vince Mar 11 '16 at 18:08
  • I wouldn't make the PlayerManager a singleton. I would create one instance of the PlayerManager and pass that instance to the classes that needed the player information. Generally, when creating a game, you use the [model / view / controller pattern](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller). Take a look at my article, [Dice Game](http://java-articles.info/articles/?p=460) to see how I handled the GUI model. – Gilbert Le Blanc Mar 11 '16 at 18:23
  • Side note: the easiest way to build singletons is to use an enum (which does imply that using a singleton is the best option; but if you think you need a singleton, there is really no need any more for that private constructor static getter any more; now that we have enums) – GhostCat Mar 11 '16 at 18:31
  • @Jägermeister It's also nice to note that enum singletons are thread-safe and prevent reflection attacks. No more double-checked locking! But sadly, singletons have became an anti-pattern, since global state is frowned upon (especially in these cases, where it is absued for simplicity). The OP should try to avoid using a singleton. – Vince Mar 11 '16 at 20:25
  • Well, and that is for good reason: global state always comes with drawbacks. Many people didn't understand that "singleton" is not the answer to that. They thought: "hey, there is a singleton pattern; so global state is ok". But the original point of the GoF pattern was: if you really really cant avoid global state; then "singleton" is a way to implement that. – GhostCat Mar 11 '16 at 21:27

0 Answers0