Это не спам, а субботние набросы)

Если твой язык не позволяет тебе хранить глобальную ссылку, воспользуйся фабричным конструктором. Я так и не понял, какую проблему ты решаешь DI’ем

Состояние чего?

Синглтона по-видимому

А зачем ему состояние менять, так кто-то делает?

Ни разу не встречал такого

Хотя может если домен в редаксе или стор, правда это вообще из другой оперы

Точно не знаю, не уверен

обнулять стейт для каждого unit-теста

Ну может тогда в каждом тесте стейт по новой создавать

Обнулить- освободить ресурсы?

Ребят, есть ощущение, что каждый говорит о чём-то своём) Эти вопросы, на мой взгляд, нужно разбирать на примере конкретных проблем и решений. А на тему «Проблема Singletone’ов» можно и доклад для CocoaHeads сделать

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

Можно после ближайшего CocoaHeads в баре обсудить)

Треугольник этот обычно упоминается совсем в противоположном смысле: возможно выбрать только 2 из 3 — если хочется быстро и качественно, то это дорого; дешево и качественно — долго; быстро и дешево — некачественно. А ты пишешь немного не про то, а про ухудшение качества ведёт в дальнейшем к росту стоимости, а это уже к треугольнику не относится.

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

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

не, погоди, если быстро и качественно выбрали, то на бюджет не смотрим, нанимаем за оверпрайс в 2-3 раза самых крутых программистов

Бюджет не бесконечен. Представь что ты инвестор, и тебе говорят: на бюджет (то есть твои деньги) не смотрим... Думаю, моя мысль понятна)

Мысль понятна, но она обозначает, что мы выбираем сроки и цену, а не качество ;)