Почему Singelton - плохая практика?

  • Автор темы Духовность™
  • Дата начала

Mols

Новичок
korchasa
100%. Я ж только за.
На том же агиле и говорят "раньше пхали всё что можно в сиглтоны, обнаружили, что есть неудобства, сейчас пхаем минимум, неудобства решаем так и так"

AmdY
Хм... когда "обычно можно заменить" так синглтон и не нужен.
Использование любого инструмента (особенно добавляющего неудобоств) там где он не нужен - это само по себе не гуд.
 

whirlwind

TDD infected, paranoid
Синглтон - отличная и полезная штука. К сожалению, не многие понимаю что значит - _единственный экземпляр_ - который передается так же как и любой другой объект. Если экземпляр никуда не передается, то он и не нужен. Реализация синглтона в php - через статический инстанциатор - полный отстой! Она извращает смысл синглтона как обычного экземпляра и поощряет использование синглтона как глобальной точки доступа к экземпляру.

PS. Вообще синглтон - это нефункциональное требование. Это - ограничение реализации. Например, банкомат не может иметь более одного приемника кредитной карты. А обращение к таким экземплярам через getInstance переводит пользовательские классы в зависимость от нефункционального требования.
 

AmdY

Пью пиво
Команда форума
korchasa
setInstance можно сделать по принципу сиглтона, в случае существавания выбрасывать исключение.
whirlwind
+1, а то мы бросились обсуждать его не как порождающий паттерн, а как замену реестра для таскания картошки из углей, что действительно - плохая практика.
 

korchasa

LIMB infected
Синглтон - отличная и полезная штука. ...
На практике, большинство объектов требующие глобального доступа имеют это требование. Отсюда и ноги. Тот же registry точно так же гарантирует наличие единственного экземпляра. И точно так же "поощрает" его использование где надо и где нет.
 

whirlwind

TDD infected, paranoid
korchasa под большинством ты имеешь в виду выкладки Фаулера? :D Не стоит так безоговорочно принимать его подходы в тех случаях, когда речь идет о разных языках. Как показывает моя практика, то что в одном языке проходит легко и незаметно (например статические вызовы java), то в других языках вызывает немало вопросов и головную боль (начиная с того же setUpBeforeClass в PHPUnit, слизанного с JUnit один-в-один).
 

korchasa

LIMB infected
whirlwind
Под большинством я имел ввиду присутствующих здесь. Про Фаулера я ни слова не сказал.
 

whirlwind

TDD infected, paranoid
У большинства она, примерно, в одном ключе.
...
Под большинством я имел ввиду присутствующих здесь.
Интересно, откуда такие выводы? Аудит проводил? Лично я тут кода не видел. А код Фаулера, настаивающего на том, что де реестр дб статический видел. Почти не сомневаюсь, ты тоже. Так с чего мне предполагать что ты имел в виду большинство здесь присутствующих, а не одного из папиков, которые этот мейнстрим и создают? :D
 

korchasa

LIMB infected
whirlwind
Ну ок. Буду говорить про себя, а ты уж сам решай насколько это актуально для веба.

Текущий проект - опердень. 5 уровней: Контроллеры, Представление, Сервисы, Модели, потроха Фреймворка
Объекты, к которым хочется доступа из нескольких слоев:
- текущий пользователь КСП - хорошо бы синглтон, чтобы можно было разлогинить из сервиса, например
- ACL текущей сделки КП - хорошо бы синглтон, чтобы нормально работали кэши внутри ACL
- workflow текущей сделки КСП - синглтон не нужен
- валидатор текущей сделки КП - хорошо бы синглтон, чтобы кэшировать результат
- калькулятор текущей сделки КП - хорошо бы синглтон, чтобы кэшировать результат
- кэш КПФ - хорошо бы синглтон, чтобы хранить дескриптор
- конфиг КСМПФ - можно и не синглтон, все равно inmutable и быстрый
- соединение с БД СМФ - обязательно синглтон (как минимум аудит запросов)
- объект доступа к ФС Ф - хорошо бы синглтон, чтобы кэшировать локаторы файлов
- лог КСМПФ - синглтон, чтобы хранить дескриптор
- отправляльщик писем КС - синглтон не нужен
- запрос КСП - хорошо бы синглтон, чтобы роутинг мог менять значения
- ответ КС - синглтон, ибо разные части заполняются на разных уровнях
- тут мне надоело
 

AmdY

Пью пиво
Команда форума
собственно, прослеживается проблема, которую поднял whirlwind, похоже ты используешь одиночку для замены глабалс, чтобы телепортировать данные между уровнями.
у тебя архитектура построена так, другое дело, хорошо это или плохо, но это не singleton, а что-то вроде service locator. если бы я не был уверен, что ты подкован в вопросе лучше меня, я бы спорил и слюной захлёбывался, а так буду долго думать и ломать голову.
 

korchasa

LIMB infected
AmdY
Не верь мне. Там где написано синглтон, я имел ввиду, где хорошо бы иметь один экзепляр. Синглтон у меня один lmbToolkit ;)
 

Ragazzo

TDD interested
Почитаешь так, почитаешь треды и осознаешь свою несостоятельность в проектировании архитектур и паттернах(
 

whirlwind

TDD infected, paranoid
AmdY
Не верь мне. Там где написано синглтон, я имел ввиду, где хорошо бы иметь один экзепляр. Синглтон у меня один lmbToolkit ;)
Я понял, что ты говоришь об синглтоне-экземпляре, а не о синглтоне-интерфейсе. Я тока не понял, что тебе мешает это сделать и где тут несоответствие с тезисом в #23 ?
 

AmdY

Пью пиво
Команда форума
korchasa
lmbToolkit - это вроде реализации примесей, который просто обрастает методами, он никак аналог одиночки, скорее замена реестра.
 

korchasa

LIMB infected
korchasa
lmbToolkit - это вроде реализации примесей, который просто обрастает методами, он никак аналог одиночки, скорее замена реестра.
Его прелесть в том, что как ты реализуешь метод, так и будет. На реестр он меньше похож, чем на singleton, т.к. объект создается "внутри", а не в каком-нибудь бутстрапе.
 

whirlwind

TDD infected, paranoid
Кстати, кеширование на самом деле нужная штука. И решается она элементарно просто - делаем декоратор, который и кеширует результаты вызовов. Я тут вообще никакой связи с темой не вижу.
 
Сверху