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

maXmoну например, ... (Дцен поскипан) - самый прозрачный способ реализации кучи данных в языках, не поддерживающих неооп.

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

softwarer
NotGonnaGetUs
maXmo
ну например, ... (Дцен поскипан) - самый прозрачный способ реализации кучи данных в языках, не поддерживающих неооп.

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


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

maXmo
ну ладно, как ты решить такую вещь: есть у меня хэш-таблица с настройками, где мне её разместить?


Задачи "есть хэш-таблица" - нет. Это уже решение.

Хотя о чём тут говорить, если у вас на форуме по c# умудряются формы через статик поля связывать...

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

Посмотри, н-р, как работа с настройками сделана в Log4Net.

Gluk (Kazan)
+1

Хотя такая точка зрения к сожалению встречается среди руководства

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

Gluk (Kazan)
Прежде чем поучать, стоит разобраться с определениями. Слово static в C++ (Java в настоящий момент меня не волнует) ОЧЕНЬ многофункциональное. Какой из его смыслов Вы предлагаете предать анафеме ???

Ну так и разберитесь. Начните с вопроса который написал 12 ноября Knoo. С первых двух его строчек.

Gluk (Kazan)
В частности, очень интересно как вы определите методы класса, которые можно будет использовать в Win API как Callback или экспортировать в DLL к примеру ?

О, хотите войнушку? Тогда говорю: Win API дерьмо.

А создание callback методов прямо ложится на паттерн комманда, который можно реализовать через анонимные классы в java или делегаты в c#.

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

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

"Любое утверждение ложно, даже это" (с).

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

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

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

Думаю, каждый из нас останется при своём мнении :)

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

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

Жалко нет времени приводить примеры.


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

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

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


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

Меня вполне устраивает стандартная реализация.
Статик метод возвращающий количество мс от базовой даты и скрывающий доступ к таймеру
+ класс для представления этих мс в удобном виде (форматирование, перевод в другие тайм зоны, етс).

Статик метод в данном случае является упрощением класса-синглтона представляющего уникальный в системе объект таймер и содержащий один метод.

Если "простенькую" задачу рассматривать не в вакууме, то могут появиться другие варианты решения.


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

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



maxmo
Сидят ли эти объекты в списках, приватных членах, локальных переменных методов - все как один встали и переконфигурировались.

Уже посмотрел на log4net? :)

Gluk (Kazan)
Да мне вощем пофигу, мне за работу с ним платят деньги


Правильно, вам пофигу.
Вы работаете с г* и используете аналогичные приёмы, потому что подругому нельзя.
Но от этого г* не становится не г*.

Gluk (Kazan)Хотите обидеть ? Напрасно, я не обижаюсь
С своей колокольни считаю говном то чем занимаетесь Вы :)

Зачем же вы так? Я добрый и миролюбивый человек. К тому же влюблённый.

А почему вы считаете написание кода, с которым можно работать без мата, гавном? :)

softwarerТо все это замечательно, но к хорошему или плохому дизайну отношения не имеет.
Имеет прямое отношение.

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

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

softwarer
Это и есть обоснование отказа от статиков, я правильно понимаю?

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

Обоснование - элементарное следование правилу сокрытия деталей реализации.

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

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

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

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

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

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

Ну, молодые разработчики - это известная ваша песня.
Причём тут "кривое решение сегодня" мне решительно не понятно.
Кривым решнием будет вынести данные на всеобщее обозрение, и в светлом будущем осваивать тонкости русского мата, пытаясь охаратеризовать принятое ранее кем-то умным решенее.

softwarer
Еще раз: ни хрена не нужно отслеживать. Нужно программировать надежно, так, чтобы потребность отслеживать не возникала.

О, да. Зарядил, так зарядил.
"Нужно" чтобы был мир во всём мире. И что с того? Как этого добится?

Программировать надёжно - это значит фигачить куда попало статики?

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


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

Про "нужно" я уже написал.

"Надёжные" классы зависящие от статик членов, придётся все до одного изменить, если окажется, что статик член нуждается в модификации. Фактически абстракции более высокого уровня оказываются завязаны на низкоуровневые утилитные классы/методы. Связывание, связывание и связывание вот к чему это приводит. И заодно к нарушение ОSP.
На свалке место таким "надёжным" классам.


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

Кто там, что писал про передёргивания?

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

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

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

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

вы говорите, что большое количество классов означет кривую технологию разработки и называете её типичной для java.

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


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


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

Всё остальное - ваши фантазии на почве не знаю чего.

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

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

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

**************************************************************
Модератор:
отредактировано


Восстанавливаем хистори:


Не существует бинарного критерия - это хорошо/это плохо. Я обозначил один из них.


Вы отвергаете мой критерий. Обоснование не понятно. Вводите другой критерий.


Т.к. обоснование против моих слов не приведено, я просто выражаюсь против вашего критерия.

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

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

Я что-то придумываю?


Ваш ответ мне не ясен. Мы говорили не о хорошем или плохом дизайне, а о вполне явно обозначенных способах определить какое из двух решений лучше. Итого: вы не поняли о чём я толковал.


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

Всё.

Где я "Вы сказали ровно то же, что и я"(с) в упор не вижу.



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

Я вас конечно люблю, но давайте оставим эти глупые придирки.
Я ещё 256 раз вам повторю - статики бэд дизайн - и при этом не буду произносить 65536 if/else описыващих частные случаи, когда нельзя, но всё-таки можно.

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

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

Ну и слава богу.

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

Не надо ещё раз. Почитайте что вы пишите.



Оценка качества кода по количеству "реальных связей".


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


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

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

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

softwarer
Прискорбная ситуация, когда человек не понимает сути и тупо-попугайно декларирует слоган.

Давайте будем искренне друг с другом. Вы меня называете тупо декларирующим слоган человеком? :)

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

А как же это "Еще раз: ни хрена не нужно отслеживать" (с) ? То говорите, что не нужно, то говорите, что нужно начиная с 65-го года. Определитесь.

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


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


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

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

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

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

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

Ох, вы и фокусник. А предложение вы продолжили с большой буквы для красоты? :))

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

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

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

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


Ну, я тогда снова за археологию возьмусь.



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

Хотя с тем, что "Java не х...я" - соглашусь :)

Вероятно, неудачно было выбрано цитирование.

Модератор:
не удачно Вами был выбран текст, который я забил звездочками.