NotGonnaGetUsАга, просто ходячий анекдот.
Очень похоже на то.

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

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

NotGonnaGetUsЕсли количество классов велико, необходимость исследовать потенциальные связи
Означает кривую технологию разработки, впрочем прискорбно типичную для явы.

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

Что ж, давайте рассмотрим простенькую задачу: реализовать функцию, возвращающую текущую дату. В каком именно классе, в каком именно формате итп - на Ваше усмотрение. Будет интересно узнать оптимальный дизайн для решения этой задачи.

maXmo softwarerБудет интересно узнать оптимальный дизайн для решения этой задачи.в джаваскрипте - new Date();
Оптимальный дизайн в джаваскрипте так существенно отличается от оптимального дизайна где-нибудь еще?

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

NotGonnaGetUsЕсли работа идёт в команде "профессионалов", если процесс ревью кода налажен на 5+, ....
То все это замечательно, но к хорошему или плохому дизайну отношения не имеет. Команда профессионалов может быть и сможет вытянуть плохо спроектированное решение, но дизайн от того хорошим не станет. Равно и наоборот.

NotGonnaGetUsто можно писать на чём угодно, как угодно, с любым количеством изуверств и извращений и надеждой, что через полгода этот код не вернётся на исправления или дополнения.
Это и есть обоснование отказа от статиков, я правильно понимаю?

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

На свете есть ровно один безопасный инструмент: инструмент, примененный вовремя и по назначению. Все прочие - опасны. А если человек, взявший инструмент, начинает песню про "учиться мне лень, возьму серебряную пулю и сходу все будет замечательно" - так и преступно опасны.

NotGonnaGetUsКроме того, срез "реальных" связей отражает только решение в текущий момент времени. Меня же больше интересует и волнует, как это решение будет эволюционировать.
Само по себе верно, но если посмотреть, на что Вы этим отвечаете, смысл получается следующим: "я приму кривое решение сегодня, думая о светлом будущем завтра". Такой смысл мне решительно не нравится, хотя увы, также типичен для молодых разработчиков.

NotGonnaGetUsВместо отслеживанием life-cycle инстанса класса, нужно отслеживать life-cycle _всех_ инстансов класса, т.к. все они имеют доступ к статик полю.
Еще раз: ни хрена не нужно отслеживать. Нужно программировать надежно, так, чтобы потребность отслеживать не возникала. Криво программировать, а потом отслеживать - забавная технология, но непрактичная.

NotGonnaGetUsВ отличии от не статических доступ к статическим членам практически невозможно контролировать.
Очень удачная фраза, прямо к моему предыдущему абзацу. Доступ не нужно "контролировать". Нужно писать классы, которые не ломаются.

NotGonnaGetUsСюда же добавляются проблемы с многопоточностью.
И какие же? На примере вышеупомянутой задачи возврата текущей даты.

NotGonnaGetUs softwarer
Означает кривую технологию разработки, впрочем прискорбно типичную для явы.

Ерунду порите. Прискорбную для вас.

Большое количество классов далеко не всегда является отражением проблем с головой, в отличии от ситуации, когда в несколько gui-форм распихан весь код приложения.
Итого, считаем:

1. Передергивание. Вы игнорируете сказанное и пытаетесь представить дело так, словно я возражаю против большого количества классов.

2. Приписывание оппоненту собственных фантазий с ожидаемым переходом на их опровержение.

3. Попытка увода беседы в сторону, никак не относящуюся к теме обсуждения.

Прискорбно для меня, говорите? Согласен. Я бы предпочел корректных собеседников.

NotGonnaGetUsМеня вполне устраивает стандартная реализация.
Статик метод .... Статик метод в данном случае является упрощением класса-синглтона ....
OK. То есть в оптимальном дизайне для подобного класса задач мы сходимся. Пойдем дальше, попробуем нащупать границу. По памяти, был у меня как раз на Яве примерно следующий код:


Ваше мнение об оптимальном дизайне для этой задачи?

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

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

NotGonnaGetUsМне, н-р, кажется не интересным повторять бесконечное число раз банальности вроде "любая х..я в ряде случаев не х..я".
Меня удивляет использованная Вами логика рассуждений "толпа идиотов, использующая нечто, делает это нечто х..й". И особенно удивляет сочетание этой логики с точкой зрения "Java не х...я", которую Вы высказывали в некоторых предыдущих беседах.

maXmo softwarerОптимальный дизайн в джаваскрипте так существенно отличается от оптимального дизайна где-нибудь еще?ээ... что?
Я спросил "каков оптимальный дизайн". Вы ответили: "В джаваскрипте - такой". Меня удивила мысль о том, что оптимальный дизайн зависит от языка ¹ , и я уточнил, правильно ли я понял, что в джаваскрипте так, а в других языках оптимум будет иным.

¹ По моим представлениям, оптимальный дизайн от языка не зависит. Другой вопрос, что ограничения языка могут не позволить реализовать этот оптимальный дизайн и потребовать тех или иных вывертов. Скажем, отсутствие наследуемых конструкторов заставляет либо тупо копировать код, либо использовать вместо конструкторов фабричные методы.

maXmoну как... хочешь объект - создай его (конструктором). Как ещё можно объект создать? Просто в джаваскрипте нет статических методов,
Ну дык с этого стоило начинать :)

NotGonnaGetUsИмеет прямое отношение. Аналогия: класс все поля, которого паблик.
Забавно: Вы сказали ровно то же, что и я ("Команда профессионалов может быть и сможет вытянуть плохо спроектированное решение, но дизайн от того хорошим не станет."), но оформили так, словно возразили.

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

NotGonnaGetUsЧтобы не было проблем с пониманием:
Использование стататик членов классов для открытия доступа к каким-то данным и операциям с ними в том случае, когда без этого можно обойтись - бэд дизайн и тупость.
OK. Я может быть и придрался бы к формулировке, но по сути ближе к согласию. Если Вы согласны, что изначальное "чаще всего" сводится к этому утверждению, то мы пришли к согласию.

NotGonnaGetUs softwarer
Несколько секунд представлял себе Вас, делающего немудреную операцию удаления аппендицита с использованием безопасного пластикового ножа из набора для пикников.

Ну хоть развлеклись немного:)
Вот именно что.

NotGonnaGetUs softwarerНа свете есть ровно один безопасный инструмент: инструмент, примененный вовремя и по назначению.
Нет.

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

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

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

NotGonnaGetUs softwarerЕще раз: ни хрена не нужно отслеживать. Нужно программировать надежно, так, чтобы потребность отслеживать не возникала.
О, да. Зарядил, так зарядил.
"Нужно" чтобы был мир во всём мире. И что с того? Как этого добится?
А это мы уже обсуждали. Писать объекты, которые не падают от "неправильного порядка инициализации свойств", которые не выдают NullPointerException вместо толковой диагностики и так далее. Попросту говоря, вернуться к истокам ООП - а именно к модульному программированию - и понять, что такое модуль и зачем он нужен - это на этапе дизайна. Ну а на этапе реализации - просто грамотность, техника кодирования.

NotGonnaGetUsПрограммировать надёжно - это значит фигачить куда попало статики?
Программировать надежно - это значит программировать надежно. Этой теме посвящены книги, в частности уважаемая мной монография Майерса.

К сожалению, прискорбно часто встречается лозунговая политика, типа "структурное программирование - это программирование без goto", "ООП - это программирование без case" или как у Вас, "что-то хорошее - это программирование без статиков". Прискорбная ситуация, когда человек не понимает сути и тупо-попугайно декларирует слоган.

NotGonnaGetUsА отслеживать нужно. Просто необходимо. Потому что подругому нельзя узнать, как используется какой-то код и какие последствия будут от его изменения, если только перед этим сам его не написал и не выучил при этом на изусть.
О! Просто замечательно. Начиная примерно с 65-го года люди думали, мучились, придумывали то самое модульное программирование, развивали идеологию, которая сейчас называется "инкапсуляция", все ради решения одной задачи: иметь возможность изменить код, не опасаясь сломать что-то в другом месте. А теперь приходите Вы, говорите "это просто необходимо" и полагаете это правильным дизайном.

NotGonnaGetUs"Надёжные" классы зависящие от статик членов, придётся все до одного изменить, если окажется, что статик член нуждается в модификации.
Полнейший бред. Я бы назвал передергиванием, но такое впечатление, что Вас уже просто занесло и Вы говорите вообще не думая.

"Все до одного приходится изменить" - если поменялся интерфейс используемого класса. Независимо от того, статики меняются или нестатики. "Никого не придется менять" - если меняется реализация используемого класса, опять же вне зависимости от того, статики меняются или нестатики.

Доказать этим "особую зависимость от статиков" - талант нужен. Особый талант, явно лежащий в стороне от традиционных дисциплин.

NotGonnaGetUs softwarer NotGonnaGetUsСюда же добавляются проблемы с многопоточностью.
И какие же? На примере вышеупомянутой задачи возврата текущей даты.
Кто там, что писал про передёргивания?
Я писал. Сможете обосновать наличие передергивания? Или просто считаете таковым каждую дырку в своей аргументации?

NotGonnaGetUsИтого, читаем:

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

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

NotGonnaGetUsЯ не телепат. А потому последующие ваши замечетельные выводы позволю себе проигнорировать.
Удобный выход.

NotGonnaGetUsВы почитайте ещё раз, что я писал. Я не предлагаю ампутировать static'и, я предалгаю не использовать их там, где их можно не использовать и использовать только там, где без них не обойтись.
Что ж, давайте таки прочитаем еще раз:

NotGonnaGetUsСтатические члены класса (поля, методы) - это чаще всего дикость и бэд дизайн, поэтому рассуждения о его плюсах/минусах мне, н-р, читать достаточно забавно.
Что-то не вижу ничего про "можно не использовать". Видимо, это моя фантазия на почве не знаю чего.

NotGonnaGetUsА меня удивляет как можно из моей фразы вывести вашу про идиотов и java.
Запомню и этот прием. Вы создаете такое впечатление, что я как-то связал эти понятия.

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