changed FPlayerManager.java

[MishaNeYT]

Легче вместо HashMap<String, FPlayer> использовать Collection либо Set

[MishaNeYT]

Только что заметил FPlayer.class HashMap<String, Mail> сюда тоже лучше использовать Collection или Set

[TheFaser]

Мне кажется не нужно использовать обычный collection, потому что uuid является универсальным ключом и метод .get у мапы намного быстрее и лучше будет, если я с помощью стрим апи буду искать игрока (а getPlayer самый используемый метод). Типо лол, зачем изобретать велосипед, когда есть мапа?

[DrupalDoesNotExists]

Прекрасно заработало бы, если бы ещё понимать как эти структуры работают, в чём их различие и почему не стоит заменять словарь массивом.

Объясняю, почему идея полностью мусорная:

HashMap ассоциирует ключ со значением. Делает он это таким образом: создаёт массив, все ключи прогоняет через хэш-функцию, которая превращает эти ключи в числа. Потом эти числа клямпят до [0, длина массива) и трактуют как индекс. Т.к. изменить элемент по индексу или его получить - это O(1), то и HashMap тоже O(1).

Collection это вообще интерфейс для всех классов-врапперов, которые являются списками чего-либо (Set, List и т.п.). Он не указывает ни на что конкретное. ArrayList - тоже Collection и Set тоже Collection и Queue тоже Collection, даже Stack будет Collection.

А Set это тот же List, только он контролирует уникальность значений. И нахождение значения в нём будет идти со скоростью O(n), где n - длина этого Set'а. В HashSet'е (имплементации Set'а) используется такая же хэш таблица как и в HashMap, но она нужна, чтобы точно была уникальность.

Так для чего из воздуха обменивать O(1) на O(n)? Особенно с учётом, что первая упомянутая мапа вообще хранит в себе тонны мусора, которые могут неограниченно и бесконтрольно расти до огромных значений? Только чтобы добавить пару сотен итераций в лучшем случае, а в худшем пару тысяч, сотен тысяч или миллионов даже.