powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Singleton vs Static members
4 сообщений из 54, страница 3 из 3
Singleton vs Static members
    #34148360
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer NotGonnaGetUsИмеет прямое отношение. Аналогия: класс все поля, которого паблик.
Забавно: Вы сказали ровно то же, что и я ("Команда профессионалов может быть и сможет вытянуть плохо спроектированное решение, но дизайн от того хорошим не станет."), но оформили так, словно возразили.

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


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

Код: plaintext
1.
2.
3.
nggu:

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

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

Код: plaintext
1.
2.
3.
softwarer:

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

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

Код: plaintext
1.
2.
3.
4.
5.
nggu:

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

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

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

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

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

Код: plaintext
1.
2.
3.
4.
softwarer:

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
nggu:

Имеет прямое отношение. 

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

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

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

Всё.

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



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

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

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

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

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

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

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

Код: plaintext
1.
2.
3.
softwarer 

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


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

Код: plaintext
1.
2.
3.
nggu:

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

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

Код: plaintext
1.
2.
3.
4.
5.
softwarer:

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

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

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.
Запомню и этот прием. Вы создаете такое впечатление, что я как-то связал эти понятия.


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

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

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

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

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

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

Модератор:
не удачно Вами был выбран текст, который я забил звездочками.
...
Рейтинг: 0 / 0
Singleton vs Static members
    #34148361
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Четал. Понравилось. Согласен с обоими.

C уважением
Lord Mayton
...
Рейтинг: 0 / 0
Singleton vs Static members
    #34149110
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все еще жду ответ на свой вопрос
...
Рейтинг: 0 / 0
Singleton vs Static members
    #34150548
dejavew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
nggu...Речь шла о статиках.
Я говорил о том, что статики приводят к более тяжёлому коду, т.к. его труднее исследовать, потому что к статикам доступ имеет больше количество классов из большего количества контекстов...

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

Так все-таки, уважаемые softwarer и nggu , не могли бы вы более детально и адресно обсудить конкретную проблему: почему доступ N классов из M контекстов к статическому методу (getInstance()) общедоступного (public) синглтона лучше/хуже (правильнее/бэддизайнее) доступа тех же самых N классов из тех же самых M контекстов к общедоступному (public) статическому члену любого другого класса, который не синглтон?
(N и M, понятное дело - равны бесконечности).

З.Ы. ***************************************************************8
...
Рейтинг: 0 / 0
4 сообщений из 54, страница 3 из 3
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Singleton vs Static members
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]