Почему внедрение шаблона Singleton в Java-коде (иногда) считается анти-шаблоном в Java-мире?

Ответ 1

Тестирование

Одна из причин заключается в том, что синглтоны нелегко обрабатывать с помощью единичных тестов. Вы не можете контролировать экземпляр и по своей природе может сохранять состояние через вызовы.

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

Рамки, такие как Spring, будут управлять жизненным циклом своих объектов и часто создавать одиночные точки, но эти объекты вводятся в их зависимые объекты каркасом. Таким образом, сама кодовая база не рассматривает объекты как одиночные.

например. вместо этого (например)

public class Portfolio {
   private Calculator calc = Calculator.getCalculator();
}

вы бы ввели калькулятор:

public class Portfolio {
   public Portfolio(Calculator c) {
      this.calc = c;
   }
}

Таким образом, объект Portfolio не знает/заботится о том, сколько экземпляров Calculator существует. Тесты могут вводить манекен Calculator, облегчающий тестирование.

Concurrency

Ограничиваясь одним экземпляром объекта, параметры для потоковой передачи ограничены. Доступ к объекту singleton может быть защищен (например, посредством синхронизации). Если вы можете поддерживать несколько экземпляров этих объектов, вы можете настроить количество экземпляров на потоки, которые у вас есть, и увеличить параллельные возможности вашей кодовой базы.

Ответ 2

Мое личное мнение заключается в том, что оно нарушает принцип единой ответственности. Объекты Singleton отвечают как за свою цель, так и за контроль над количеством экземпляров, которые они производят, и я думаю, что это неправильно.

Вот почему многие люди делегируют элемент управления объекту factory.

Ответ 3

[Mutable] Singleton - это анти-шаблон анти-шаблона.

Значимым основным анти-шаблоном является глобальное состояние (или окружающее состояние). В глобальном состоянии у вас есть большой блог зависимости в вашей программе. Это влияет на тестирование, но это всего лишь одна часть последствий плохого программирования.

Сложив это, Singleton добавляет совершенно ненужный уровень сложности, просто объявив изменяемые поля static.

Ответ 4

Синглтоны как таковые не обязательно являются анти-паттернами, но они имеют только несколько преимуществ и становятся антипаттернами, когда они используются неправильно (что часто случается).

Часто синглтоны вообще не являются одиночными, но "глобальными переменными в маскировке". Кроме того, часто они используются, когда свойство "только один экземпляр" на самом деле не является преимуществом. (что снова уравновешивается тем фактом, что много раз реализация ошибочна в то же время).

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

Если вы хотите контролировать экземпляр, вам нужно сделать это вручную в какой-то момент на ранней стадии программы, но тогда вы могли бы просто создать один экземпляр обычного объекта и передать его дальше.
Если порядок уничтожения вызывает какое-либо беспокойство, вам также необходимо выполнить его вручную. Один автоматический объект в основной функции намного чище и проще.

Ответ 5

Есть много требований, которые могут возникнуть у синглтона:

• ленивая инициализация;
• правильная утилизация;
• scoping (по одному на поток, например).

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

Ответ 6

Странно. Похоже, что некорректная реализация Singleton - это "анти-шаблон", а не сам синглтон.

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

Большинство инфраструктур DI позволяют создавать экземпляр класса как Singleton, он просто обрабатывает это для вас. Если вы сами решите сделать DI, инъекция синглтона не является проблемой. Синглтон также можно тестировать, и если вы используете DI для его инъекции, он не делает класс неустойчивым.

IMO, как и любой другой образец там (включая DI и IoC), это инструмент. Иногда он подходит, иногда это не так.