Синглтон лучше статики?

Question

Итак, у меня есть класс игрока в моей игре. По логике вещей, необходим только один объект игрока (одиночный игрок). Но множеству разных классов необходим доступ к объекту игрока. (т. е. карты должны знать, где находится игрок, а также камера и враги должны взаимодействовать с игроком и т. д.).

У меня есть несколько вариантов.

Либо я мог бы передать этот объект игрока всему, что ему нужно, что является громоздким. (Внедрение зависимости, я думаю, это называется)

Просто сделайте это статичным.

Сделай его одним.

Каковы плюсы / минусы каждого?

Answer 1

Я бы не использовал здесь Singleton или статическую переменную, а вместо этого передавал бы экземпляр Player классам, которые нуждаются в этом через сеттеры. Если вам нужен только один экземпляр игрока - звоните только new Player() один раз: -)

Смотрите мой взгляд на синглетоны здесь . Краткое резюме: их типичное неправильное использование (избегая «громоздких» сеттеров) нарушает ОО и снижает качество дизайна.

Статические переменные вырезаются из той же ткани, что и Singletons, вместе с Monostate (нестатические геттеры, статические данные, конструктор - «фабрика»). Избежать их. Подумайте, если бы вы сделали все статичным: игрок, карта, камера, враги и т. Д. Вы бы избежали большого количества «громоздких» сеттеров. Но это ОО? Когда вы закончите свою игру, можете ли вы повторно использовать свои алгоритмы поиска пути, AI-алгоритмы и т. Д. В другой игре, или у них слишком много глобальных переменных (Singletons и др.), Специфичных для вашей текущей игры, навсегда сожженных в них?

Answer 2

Итак, ваши варианты:

Просто сделайте его статическим.Сделайте его синглтоном.

И то, и другое эффективно превратит его в глобальную переменную.Я не большой поклонник глобалов: они усложняют все тестирование и отладку.

Плюсы: Упрощенный доступ

Минусы: Оченьвысокая связь (что, если вы хотите сделать игру для двух игроков?);Добавляет сложность к тестам;Смена игрока в одном месте может иметь неожиданные последствия в других местах.

Я мог бы передать этот объект игрока всему, что ему нужно, что является громоздким.(Внедрение зависимостей, я думаю, это называется)

Плюсы: Нижняя муфта;Облегчает тестирование;Вы можете передавать копии проигрывателя другим классам и уменьшать вероятность побочных эффектов.

Минусы: Необходимость передачи ссылок Player делает API немного более сложным, но частичноего можно уменьшить с помощью инфраструктуры внедрения зависимостей, такой как Guice .

Answer 3

Синглтоны могут реализовывать интерфейсы, которые могут использоваться для ссылки на синглтон. то есть вам не нужны жестко запрограммированные ссылки на одиночный код в вашем коде. Это облегчает юнит-тестирование, если вам нужен другой экземпляр для тестирования.

public interface Printer {
   public void print(String line);
}

public enum ConsolePrinter implements Printer {
   INSTANCE;
   public void print(String line) {
       System.out.println(line);
   }
}

// to print to the screen
Printer printer = ConsolePrinter.INSTANCE;

// for testing purposes.
Printer printer = createMock(Printer.class);

Answer 4

Я бы не стал делать это статичным.Вы хотите, чтобы ваш код можно было многократно использовать, и проигрыватель, безусловно, является объектом, которому может потребоваться несколько экземпляров в альтернативном проекте.

Я бы создал простые методы getAttribute (), editAttribute, которые возвращают или редактируют нужный мне атрибут.

Другой вариант - просто сделать общедоступные атрибуты общедоступными в классе проигрывателя, хотя я бы предпочел опцию методов get / edit.

Answer 5

Использование синглтона дает вам возможность расширить базовый класс и предоставить альтернативные реализации Player, а использование статического метода теперь допускает такую ​​гибкость.

Другой момент заключается в том, что «концептуально» игрок является объектома не класс.

Answer 6

Помимо преимуществ, предоставляемых Java Setter и Getter , я не могу даже подумать о каких-либо новых, которые одноэлементный шаблон (public static Type getInstance()) дал бы вам над публичной переменной (public static Type var).

Но в целом всегда лучше (из будущего pov) контролировать доступ к переменным-членам (особенно доступ извне к классу, который имеет эту переменную-член), поэтому я бы порекомендовалprivate static переменная с публичным геттером.Который находится где-то между синглтоном и публичной статической переменной.