Философия разработки на примере синглтона

[Roy]

От синглтона вреда никакого, в отличие от DI
И именно юнит тесты - ценность которых переоценена на порядки - основной источник проблем с DI. Задумайтесь над очевидными фактами
1. Ошибки происходят от сложности
2. Чем больше ошибок делается, тем больше их "ускользает" от тестирования
3. Цель тестирования - минимизация ускользнувших ошибок
4. Юнит-тесты DI добавляют сложности

Складывая 2+2 получаем, что DI вреден для тестирования. Упс

(Еси чо, я не против дозированного использования DI in UT, но только дозированное, а не повсеместное, как того требуют программистские представления о крутизне)

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности? Наоборот, он заставляет делать loosely coupled design, что есть гуд. А синглтон - это мина замедленного действия. Сейчас может быть всё нормально, а через несколько лет надо будет что-то поменять или протестировать - вот тогда проблемы и всплывут.
Или вы к DI относите всякие IOC фреймворки типа ninject? Тогда я с вами согласен

[Big Cheese]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности?

Если не сложно, пример нормального использования DI не приведете?

[Pantigalt]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности? Наоборот, он заставляет делать loosely coupled design, что есть гуд.

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

[Roy]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности?

Если не сложно, пример нормального использования DI не приведете?

Ну как бэ... например data access layer определить через интерфейс и передавать этот интерфейс в конструктор классу, который пишет в базу. Теперь можно тестировать класс без базы.

[Roy]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности? Наоборот, он заставляет делать loosely coupled design, что есть гуд.

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

Ну понятно, что говнокод писать быстрее без DI. Но всё временное говно имеет тенденцию становится постоянным и застывать. А переписать никто не удосуживается. В результате имеем то, что имеем.
Если для себя пишете или minimum viable product - то тогда канешна всё можно. Но в устоявшемся проекте - ну его нах. Вы юнит тесты используете? Как при этом умудряетесь без DI обойтись?

Я не очень понимаю, почему так сложно писать с использованием DI? Я не имею в виду всякие IOC библиотеки типа ninject. Просто определять логические компоненты через интерфейсы. Особенно то, что будет потом торчать наружу типа базы, файлов, сервисов.

П.С. Не очень уловил аналогию с алгоритмами.
П.С2. Что вы имеете в виду под контекстом?

[major Major Major Major]

Ну как бэ... например data access layer определить через интерфейс и передавать этот интерфейс в конструктор классу, который пишет в базу. Теперь можно тестировать класс без базы.

То есть городить тучу интерфейсов для того что бы тестирование было "легче". Правда оно будет при этом мягко говоря неполным зато отчет по code coverage отлично выглядит. Взводить тестовую базу автоматически и прогонять на ней полноценную работу внутренней логики + слой доступа + логика базы конечно гораздо скучнее.

[Roy]

Ну как бэ... например data access layer определить через интерфейс и передавать этот интерфейс в конструктор классу, который пишет в базу. Теперь можно тестировать класс без базы.

То есть городить тучу интерфейсов для того что бы тестирование было "легче". Правда оно будет при этом мягко говоря неполным зато отчет по code coverage отлично выглядит. Взводить тестовую базу автоматически и прогонять на ней полноценную работу внутренней логики + слой доступа + логика базы конечно гораздо скучнее.

Вы имеете в виду enд-to-end testing? Такое, безусловно, необходимо, никто не спорит. Но с каждым билдом обычно не погоняешь, особенно если он на каждый чекин происходит. Вы с понятием unit testing знакомы?
Городить кучу интерфейсов не обязательно. Обычно CRUD интерфейса хватает в 90% случаев.

[major Major Major Major]

Но с каждым билдом обычно не погоняешь, особенно если он на каждый чекин происходит

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

Вы с понятием unit testing знакомы?

И даже знаю как их писать так что бы от них было больше пользы чем затраченного времени.

[АццкоМото]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности?

Оно добавляет сложности по определению. Если в коде до введения DI вот в этом месте был объект типа А, а после введения - может быть А, КагбэА, ТестовыйА, АПопробуюВотТакА и Б - то сложность возросла. Тут нечего обсуждать

Наоборот, он заставляет делать loosely coupled design, что есть гуд.

Вовсе нет. Дизайн ради дизайна не есть гуд.
Если сегодня я пишу
DBProvider p = new DBProvider();

а завтра мне нужно сделать внезапно IGenericDBProvider, MyRealDBProvider, MyTestDBProvider и DBProviderSureshAskedFor()

И объявлять все это каким-нибудь странным образом типа @InjectHellKnowsWhatExactly - ничего хорошего само по себе это не несет. Хотя программистское сердце может воспылать любовью - как клево! Лох бы так не написал. (Лох тем временем дописал эту поделку целиком и ушел к конкурентам на +20%, но мы все равно будем пулять какашками в его "говнокод")

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

Я не понимаю, что там может всплыть. Расскажите - реально интересно. Однако на аргументы типа "а вот если через несколько лет..." я ложил болт. Через несколько лет может ничего и не понадобиться, я могу работать в другой конторе, может случиться ядерная война или вообще меня зарежет обдолбанный негрила. Если так рассуждать, лучше бросить все и уйти в монастырь

[АццкоМото]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности?

Если не сложно, пример нормального использования DI не приведете?

Ну как бэ... например data access layer определить через интерфейс и передавать этот интерфейс в конструктор классу, который пишет в базу. Теперь можно тестировать класс без базы.

А потом определить интерефейс к классу и тестировать класс без класса. Ништяяяк!

[Roy]

Но с каждым билдом обычно не погоняешь, особенно если он на каждый чекин происходит

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

А если баз - десяток? А также надо гонять тесты на dev машинах. Если тебе какие-то базы на dev машине нафиг не нужны - зачем ставить и держать up-to-date? Есть вообще тулзы которые unit testы постоянно гоняют в бэкграунде в то время как вы пишите код. Нахрена иметь этот дополнительный гемор с базами?

Вот как это делается в идеале: Все _важные_ компоненты, которые надо тестировать - тестируются отедельно с обрубленнoй базой. Data access layer тестируется вместе с тестовой базой. Таким образом можно гонять тесты независимо, даже если база поломана или нафиг не нужна вам лично.

Также есть intergration tests которые гоняют всё вместе.

Вы с понятием unit testing знакомы?

И даже знаю как их писать так что бы от них было больше пользы чем затраченного времени.

Расскажите, пожалуйста.

[Roy]

Я всё таки не очень понимаю, почему нормальное использование DI добавляет сложности?

Если не сложно, пример нормального использования DI не приведете?

Ну как бэ... например data access layer определить через интерфейс и передавать этот интерфейс в конструктор классу, который пишет в базу. Теперь можно тестировать класс без базы.

А потом определить интерефейс к классу и тестировать класс без класса. Ништяяяк!

Ну зачем ёрничать-то? Вы юнит тест используете? Ваши аргументы очень похожи на аргументы тех, кто не любит unit testы.

[Roy]

Вовсе нет. Дизайн ради дизайна не есть гуд.
Если сегодня я пишу
DBProvider p = new DBProvider();

а завтра мне нужно сделать внезапно IGenericDBProvider, MyRealDBProvider, MyTestDBProvider и DBProviderSureshAskedFor()

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

Нужно IGenericDBProvider, MyRealDBProvider. Вам ведь всё равно надо писать класс MyRealDBProvider или вы data access код пишите прямо внутри бизнес логики?
Тесты пишуться с помощью мок-библиотек типа Rhino, так что тестовые классы писать не надо. Если это сложно - ничем не могу помочь. Что такое @InjectHellKnowsWhatExactly - не понял.

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

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

Я не понимаю, что там может всплыть. Расскажите - реально интересно. Однако на аргументы типа "а вот если через несколько лет..." я ложил болт. Через несколько лет может ничего и не понадобиться, я могу работать в другой конторе, может случиться ядерная война или вообще меня зарежет обдолбанный негрила. Если так рассуждать, лучше бросить все и уйти в монастырь

Если "через несколько лет" для вас не аргумент, то аргументов нет. Вы никогда не работали с кодом старше 3 лет? Если его писали приверженцы подхода "После нас хоть потоп", то лучше даже не начинать с ним работать.

[АццкоМото]

Вовсе нет. Дизайн ради дизайна не есть гуд.
Если сегодня я пишу
DBProvider p = new DBProvider();

а завтра мне нужно сделать внезапно IGenericDBProvider, MyRealDBProvider, MyTestDBProvider и DBProviderSureshAskedFor()

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

Нужно IGenericDBProvider, MyRealDBProvider. Вам ведь всё равно надо писать класс MyRealDBProvider или вы data access код пишите прямо внутри бизнес логики?

Нет-нет, суть в том, что кроме MyRealDBProvider должны быть и другие реализации, иначе где же иньекция и в чем смысл выделения интерфейса? Итого, вместо одного класса - минимум три. Это и есть усложнение. Трехкратное. Ради тестирования. А аксиома гласит - test harness должен по минимуму усложнять код. И выход - который работает в большинстве случаев - тупо DBProvider (Endpoint whatever);
В _некоторых_ случаях DI может быть полезен, но всегда нужно трижды подумать, а не бездумно поклоняться новым богам. А то 10 лет на иконостасе был Gang Of Four, а тут видите ли мода поменялась и синглтон - безусловное зло. А самому подумать вместо религии - не?

Тесты пишуться с помощью мок-библиотек типа Rhino, так что тестовые классы писать не надо.

Вот только мок-либы, только Rhino. А вы не задумывались, что не везде так? Что не все живут в мире типа база-логика-бэкэнд-вебморда?

Что такое @InjectHellKnowsWhatExactly - не понял.

Беда какая. А как же вы инжектить собираетесь? Как бы оно не выглядело в конкретной реализации, суть все равно в том, что в каком-то месте вы делаете приседание и не знаете прямо из кода, какой именно объект вам подсунут. В этом - суть

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

Да ничего хорошего оно не несет. И SQL-спагетти совершенно не имеет никакого отношения к проблеме. Уаще страшная тайна - SQL может и не быть. А может и не быть базы данных. И веб-морды.

Если "через несколько лет" для вас не аргумент, то аргументов нет. Вы никогда не работали с кодом старше 3 лет? Если его писали приверженцы подхода "После нас хоть потоп", то лучше даже не начинать с ним работать.

Я думаю, что я вас лет на 10 старше и я видел такой код, что из него торчат cathode ray tubes. Но что с того? Бывал и говнокод, бывал и прекрасный.
Капитан очевидность говорит, что если я буду писать исключительно идеальный (хм, кто даст определение?) код, я все равно не смогу развидеть то, что уже видел. И даже никак не повлияю на то, что мне еще предстоит увидеть. Неужели это так сложно?
ЗЫ. Я так понимаю, с обоснованием тезиса "синглтон - зло" не задалось, поэтому пошла демагогия

[Roy]

Нужно IGenericDBProvider, MyRealDBProvider. Вам ведь всё равно надо писать класс MyRealDBProvider или вы data access код пишите прямо внутри бизнес логики?

Нет-нет, суть в том, что кроме MyRealDBProvider должны быть и другие реализации, иначе где же иньекция и в чем смысл выделения интерфейса? Итого, вместо одного класса - минимум три. Это и есть усложнение. Трехкратное. Ради тестирования. А аксиома гласит - test harness должен по минимуму усложнять код. И выход - который работает в большинстве случаев - тупо DBProvider (Endpoint whatever);

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

Тесты пишуться с помощью мок-библиотек типа Rhino, так что тестовые классы писать не надо.

Вот только мок-либы, только Rhino. А вы не задумывались, что не везде так? Что не все живут в мире типа база-логика-бэкэнд-вебморда?

Мы вроде как конкретный пример обсуждали с базами? Естественно надо думать, если тесты не оправдывают потраченного на них времени, то их не стоит писать. Но в 70% случаев мок-либ хватает.

Что такое @InjectHellKnowsWhatExactly - не понял.

Беда какая. А как же вы инжектить собираетесь? Как бы оно не выглядело в конкретной реализации, суть все равно в том, что в каком-то месте вы делаете приседание и не знаете прямо из кода, какой именно объект вам подсунут. В этом - суть

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

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

Да ничего хорошего оно не несет. И SQL-спагетти совершенно не имеет никакого отношения к проблеме. Уаще страшная тайна - SQL может и не быть. А может и не быть базы данных. И веб-морды.

Повотрюсь, коммент был насчёт data access layer. В общем случае, DI стимулирует loosely coupled design, что обычно делает структуру программы лучше и легче поддаётся тестированию. Независимо от типа аппликэйшена.

Насчёт синглтона. Просто наберите в Гугле "Why singletons are bad". Там лучше меня обьясняют. Но если вам нравится - используйте на здровье. Свет на них клином не сошёлся. Но я бы с вами в разведку не пошёл.

Кстати, сами Gang Of Four сожалеют о том, что включили синглтон в дизайн паттерны:

Larry: How would you refactor "Design Patterns"?

Erich: [... skipped...]
When discussing which patterns to drop, we found that we still love them all. (Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.)

[АццкоМото]

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

Это абсолютно неважно: даже если суслика не видно, он есть. И значит есть лишняя сложность.

Мы вроде как конкретный пример обсуждали с базами? Естественно надо думать, если тесты не оправдывают потраченного на них времени, то их не стоит писать. Но в 70% случаев мок-либ хватает.

Боже упаси. Какой такой конкретный пример? Если вас так настроил упомянутый всуе new DBProvider() - то пусть будет SomeShitOutThere. Проблемы нужно сначала рассматривать в общем виде

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

Я соглашусь, что DI в своем простейшем виде - туда-сюда решение, типа заинитили зависимость при инициализации и довольны. Но люди же идут дальше. Кто фабрики создает на ровном месте, а кто - и вовсе Guice-ом пользуется. А там и до IOC недалеко. Вот уже и в маразме

Повотрюсь, коммент был насчёт data access layer. В общем случае, DI стимулирует loosely coupled design, что обычно делает структуру программы лучше и легче поддаётся тестированию. Независимо от типа аппликэйшена.

Повторюсь, что усложнение кода ради упрощения тестирования - богопротивно. Независимо от типа аппликейшена
Ну и это... никакого loosely coupled дизайна по сути не получается. это чистая иллюзия. самовнушение

Насчёт синглтона. Просто наберите в Гугле "Why singletons are bad". Там лучше меня обьясняют. Но если вам нравится - используйте на здровье. Свет на них клином не сошёлся. Но я бы с вами в разведку не пошёл.

Да читал я религиозные эти байки. Типа SRP нарушается. Ага. У них всегда так. Если класс "калькулятор" нравится, то все ок. А если нет - то сразу вой "как?!!! один класс и складывает и вычитает???!!! это же содом и гоморра!"
А в разведку лучше ходить одному

Кстати, сами Gang Of Four сожалеют о том, что включили синглтон в дизайн паттерны:

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

[Мальчик-Одуванчик]

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

[Roy]

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

Это абсолютно неважно: даже если суслика не видно, он есть. И значит есть лишняя сложность.

В упор не вижу сложность. Сделали интерфейс и класс. Помещать data access в отдельный класс и так желательно. Сложность в том, чтобы интерфейс отдельно определять и передавать его в конструктор?

Я соглашусь, что DI в своем простейшем виде - туда-сюда решение, типа заинитили зависимость при инициализации и довольны. Но люди же идут дальше. Кто фабрики создает на ровном месте, а кто - и вовсе Guice-ом пользуется. А там и до IOC недалеко. Вот уже и в маразме

Да, есть такие. Некоторые ещё всё инициализацию в xml config запихивают. Ну таких надо по рукам бить. Любую технологию можно довести до абсурда, если захотеть.

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

Тут надо проявлять мудрость. Чтобы не перебрать. Этим и отличается опытный программист от умного . Я бы так сказал: опыт - это знание где и когда надо сделать шорткат и написать кучу говнокода, а когда потратить немного больше времени и сделать правильно. А также знание, когда надо бросить всё нах и переписать
Я, например, часто когда начинаю, пишу как попало, лишь бы быстрее, но стараюсь разделять говно в кучки и минимизировать между ними зависимости. Важно правильно определить кучки. В дальнейшем сильно может помочь, а времемни много не занимает.

[АццкоМото]

В упор не вижу сложность. Сделали интерфейс и класс. Помещать data access в отдельный класс и так желательно. Сложность в том, чтобы интерфейс отдельно определять и передавать его в конструктор?

Блин, да у вас просто пробел в образовании. Сложность - это не тогда, когда что-то сложно сделать. Это тупо метрика. Например if (input==null) return null; добавляет единичку к цикломатической сложности по МакКейбу. А максимум по методу считается около 10-15, дальше ошибки растут уже нелинейно. (хотя многие современные подходы не учитывают тривиальные проверки при подсчете). Не о том речь, что определить интерфейс сложно. Но это - сложность. Это всегда больше ошибок. Аксиома из 101

Да, есть такие. Некоторые ещё всё инициализацию в xml config запихивают. Ну таких надо по рукам бить. Любую технологию можно довести до абсурда, если захотеть.

Хоть в чем-то мы согласны

Тут надо проявлять мудрость. Чтобы не перебрать. Этим и отличается опытный программист от умного .

Ключевое свойство программиста в том, что он всегда считает себя умнее и мудрее других программистов

[SashaKR]

Однако на аргументы типа "а вот если через несколько лет..." я ложил болт.

запомнилось: где-то 2002г мне надо было что-то подправить в каком-то мелком проекте написанном крутым (по слухам) архитектором.. в одном месте функционального кода было ровно 3 (!) строки, но зато всё было завернуто в 3 класса и 2 интерфейса, factory и т.п.. вдруг пригодится..

[АццкоМото]

Однако на аргументы типа "а вот если через несколько лет..." я ложил болт.

запомнилось: где-то 2002г мне надо было что-то подправить в каком-то мелком проекте написанном крутым (по слухам) архитектором.. в одном месте функционального кода было ровно 3 (!) строки, но зато всё было завернуто в 3 класса и 2 интерфейса, factory и т.п.. вдруг пригодится..

Вот и мне проще в такое поверить, чем в идею, что если сегодня не сделать "круто", то через 3 года все развалится

[Roy]

Однако на аргументы типа "а вот если через несколько лет..." я ложил болт.

запомнилось: где-то 2002г мне надо было что-то подправить в каком-то мелком проекте написанном крутым (по слухам) архитектором.. в одном месте функционального кода было ровно 3 (!) строки, но зато всё было завернуто в 3 класса и 2 интерфейса, factory и т.п.. вдруг пригодится..

Вот и мне проще в такое поверить, чем в идею, что если сегодня не сделать "круто", то через 3 года все развалится

У нас тоже случай был...

Был у нас один умный архитектор, который любил синглтоны.
Сделал синглтон ConfigurationCache.GetConfig(), который читает конфигурацию из базы. Потом добавил ещё несколько десятков синглтонов типа VendorCache.GetVendors(), ActionCache.GetActions(), etc. Синглтоны внутри себя использовали друг друга (особенно GetConfig), читали вовсю данные из базы, из файлов. Всё это расползлось в сотни функций и классов. В результате проект вообще нельзя было исползовать за пределами полностью настроенной среды. Понадобилось много человеко-месяцев, чтобы всё это зарефакторить и написать нормальные тесты.

С тех пор у меня на синглтоны аллергия.

[АццкоМото]

Однако на аргументы типа "а вот если через несколько лет..." я ложил болт.

запомнилось: где-то 2002г мне надо было что-то подправить в каком-то мелком проекте написанном крутым (по слухам) архитектором.. в одном месте функционального кода было ровно 3 (!) строки, но зато всё было завернуто в 3 класса и 2 интерфейса, factory и т.п.. вдруг пригодится..

Вот и мне проще в такое поверить, чем в идею, что если сегодня не сделать "круто", то через 3 года все развалится

У нас тоже случай был...

Был у нас один умный архитектор, который любил синглтоны.
Сделал синглтон ConfigurationCache.GetConfig(), который читает конфигурацию из базы. Потом добавил ещё несколько десятков синглтонов типа VendorCache.GetVendors(), ActionCache.GetActions(), etc. Синглтоны внутри себя использовали друг друга (особенно GetConfig), читали вовсю данные из базы, из файлов. Всё это расползлось в сотни функций и классов. В результате проект вообще нельзя было исползовать за пределами полностью настроенной среды. Понадобилось много человеко-месяцев, чтобы всё это зарефакторить и написать нормальные тесты.

С тех пор у меня на синглтоны аллергия.

У меня тоже случай был. Один чертило if и for использовал. Код - говно. С тех пор стойкая на них аллергия

[Roy]

У нас тоже случай был...
...
С тех пор у меня на синглтоны аллергия.

У меня тоже случай был. Один if и for использовал. Код - говно. С тех пор стойкая на них аллергия

Расскажите, как вы пишете unit test для кода, который вызывает синглтон?

[Alexandr]

.....Я-то в курсе и не буду делать new вместо getInstance()......

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