Здравствуйте, mkizub, Вы писали:
M>GoF не читал. flyweight — не слышал о таком. M>visitor — это чаще всего от бедности и неимения multimethods. Кроме того, буквально два дня назад читал список вариаций шаблона visitor — их чуть меньше десятка. Это ответ на вопрос "как его улучшить".
Имхо использовать паттерн != тупо строить те же самые конструкции, что изначально были описаны автором. Как мне кажется, это просто идея, а вариаций ее может быть сколько угодно, в зависимости от того, какова текущая задача и что позволяет язык программирования.
B>>Т.е. это и есть как раз суть паттерна — не придумывать велосипед при решении часто возникающих, хорошо описанных задач, а использовать готовые наработки.
M>А я именно это самое и написал.
Здравствуйте, mkizub, Вы писали:
M>Я же написал — о шаблонах. M>Шаблон — это "стандартное решение". Есть проблема, есть решение, стандартное, проверенное не один раз, и найденное достаточно удачным для решения этой проблемы.
Да все правильно говоришь, только ведь проблемы, решаемые шаблонами проектирования, за частую на столько общие, что с неми сталкивается любой разработчик в любом проекте. Согласен, что не все паттерны именно такие, некоторые имеют узкую специализацию, но синглтон как раз такой, общий шаблон.
M>Конечно, если впихнуть это стандартное решение одной проблемы как решение для другой проблемы — то выйдет фигня.
Конечно если начать катать квадратное, то ничего хорошего не выйдет, но и мы свами здравые люди и не в армии.
M>Конечно, ещё лучше — знать все шаблонные решения (иначе будет изобретение велосипедов), а вот конкретную проблему решать не шаблонно, а придумать ей новое решение, наиболее удачное. Это тяжело и не всегда удаётся — придумать хорошее решение — поэтому народу так нравятся шаблонные решения и шаблонный способ мышления — в случае чего можно показать книжку "паттерны проектирования" и сказать, что там так написано. Именно поэтому данное направление стало таким модным — оно позволяет снять с себя ответственность, и вообще думать поменьше.
За частую знать и нужно не для того что бы меньше думать, а для того, что бы лучше понимать других людей. Вот bolshik сказал flyweight, и я его понял, а ты нет.
M>А что в этой дискуссии? Один вычитал про Singleton, и теперь озабочен — как бы ему это сокровенное знание применить. Другие читали другие книжки, где наглядно доказывается, что применение шаблонных решений необдуманно — ведёт к хреновым результатам. И спешат поделится этим сокровенным знанием, и волшебным словом "антипаттерн".
Просто я вспомнил, когда я узнал про синглтон, и начал его писать куда не следовало. Смысл этого топика — предостережение.
M>Третьи (извини, в твой огород камень) рассказывают, что есть некий идеальный шаблон IoC (тоже замечательное шаблонное решение — но для решения очень определённого класса проблем, и не надо его совать в каждую дырку), и вот если его смешать с Singleton, то на последний падёт тень благородства IoC, и он станет не таким плохим. Как вообще можно говорить о применимости или неприменимости какого-то шаблонного решения, если ещё ничего не сказано о самой проблеме? Как только начинаются такие разговоры — то это однозначно дилетантизм, hupe и buzz-words. Обсуждать достоинства и недостатки шаблонных решений безотносительно проблем, которые они призваны решить — это полное непонимание самого понятия, самой сути "шаблонов проектирования".
Опять же про IoC я написал как наиболее простой пример правильного подхода к синглтону. Синглтон не антипаттерн, до тех пор, пока он не используется как глобальная переменная. Стоит только поразбрасать по коду Singleton.getInstance(), тут мы и начинаем огребать все прелести.
Здравствуйте, dshe, Вы писали:
D>Забавно, вроде бы я и совсем с тобой согласен (врядли кто-то будет несогласен с банальной истинной, что все хорошо в меру), но удовлетворения от этого в душе нет. Наверное потому, что почувствовал, что отношусь к одной из трех групп, каждую из которых ты так мимоходом, извините, обгадил. Ты уверен, что для того, чтобы быть услышанным, необходимо настраивать против себя весь свет?
Давай ты перечитаешь это лет через 5, и потом оценишь степень своих страданий
Здравствуйте, Nicht, Вы писали:
N>Синглтон не антипаттерн, до тех пор, пока он не используется как глобальная переменная. Стоит только поразбрасать по коду Singleton.getInstance(), тут мы и начинаем огребать все прелести.
А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"? Впрочем, про true и false я уже приводил примеры. Тоже — уникальные, глобальные и всё такое.
Кроме плохого, в глобальных переменных есть и хорошее. Небольшая программа с использованием глобальных переменных — скорее всего будет проще, понятней и эффективней, по сравнению с попыткой написать её-же без глобальных переменных. Вот в большом проекте — там да, критическая масса сложности нарастает, и в какой-то момент статические переменные становятся больше злом, чем помощью. Но ведь они, т.е. "паттерн статических переменных" в этом не виноваты, в том, что их продолжают использовать в большом проекте.
Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п. — это ровно то-же, что "предварительная оптимизация". Иногда (а по моему — чаще всего) лучше сделать минимальную программу, чтоб она работала, и потом уже заниматься оптимизацией, или расширением возможностией — и как следствие рефакторингом кода, переходом на использование некоторых шаблонов для сложных программ и т.д.
Собственно, опять к тому-же и пришли — говорить о хорошести и плохости шаблона — бессмысленно, без знания задачи, которую нужно решить.
Здравствуйте, mkizub, Вы писали:
M>Собственно, опять к тому-же и пришли — говорить о хорошести и плохости шаблона — бессмысленно, без знания задачи, которую нужно решить.
Да, все правильно.
Хотя я сторонник изначальной проработки хоть какой то архитектуры а не писания на глобальных переменных, а потом рефакторить.
Рефакторинг далеко не тривиальная задача, и лучше без нее чем с ней.
Просто мне почему то показалось, что ты проповедуешь нигилизм, и что типа шаблоны вообще знать не надо. В этом и был источник спора.
Так то я с тобой согласен.
Re[11]: класс Singleton - разобрался, но где в "жизни" приме
Здравствуйте, mkizub, Вы писали:
M>Кроме плохого, в глобальных переменных есть и хорошее. Небольшая программа с использованием глобальных переменных — скорее всего будет проще, понятней и эффективней, по сравнению с попыткой написать её-же без глобальных переменных. Вот в большом проекте — там да, критическая масса сложности нарастает, и в какой-то момент статические переменные становятся больше злом, чем помощью. Но ведь они, т.е. "паттерн статических переменных" в этом не виноваты, в том, что их продолжают использовать в большом проекте.
При чтении данного абзаца вспомнилось процедурное программирование, к чему бы это...
M>Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п. — это ровно то-же, что "предварительная оптимизация".
Тонны процедурного кода очень сложно оптимизировать до соответствия объектному подходу.
Re: класс Singleton - разобрался, но где в "жизни" применить
Забавна сама постановка вопроса темы. Шаблон нужно применять только тогда, когда горький или не очень опыт собственных проб и ошибок приведет к осознанию потребности в некотором решении, один из вариантов которого может предложить данный шаблон. Именно тогда разработчик применит шаблон в соответствии с его назначением, а к примеру, не будет компенсировать кривой дизайн системы посредством создания глобальных переменных, опошляя идею шаблона Одиночка — опять же потому что незнаком с другими типовыми решениями, посредством применения которых можно обойтись и без глобальной связности всего кода, или попросту не видит область их применения в своей задаче.
Несмотря на то, что в GoF-ы достаточно подробно описывают область применения, полезность, выгоду и etc бонусы — каждого рассматренного паттерна, без опыта работы с кодом, который они описывают, "крутость" шаблонов будет непонятна.
Здравствуйте, mkizub, Вы писали:
M>Собственно, опять к тому-же и пришли — говорить о хорошести и плохости шаблона — бессмысленно, без знания задачи, которую нужно решить.
Эта, а также все другие и ни о чем не говорящие общие фразы в контексте обсуждения конкретного вопроса вроде "нужно знать меру", "золотая середина", "истина где-то рядом" и т.п. — звучат, конечно, умно и жизненно, но не более. Обычно шаблон говорит о конкретном решении некоторой общей задачи. Конкретика задачи, конечно, всегда присутствует, но она говорит о том, стоит или нет вообще применять данный шаблон (решает или нет он стоящую перед тобой проблему), а вовсе не о том, как бы так-эдак использовать (а на самом деле — извратить) шаблон в задаче, для решения которой он вовсе не предназначен. В первом случае — поиск проверенного решения, а во втором — прокрустово ложе и копание собственной ямы.
Re[11]: класс Singleton - разобрался, но где в "жизни" приме
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Nicht, Вы писали:
N>>Синглтон не антипаттерн, до тех пор, пока он не используется как глобальная переменная. Стоит только поразбрасать по коду Singleton.getInstance(), тут мы и начинаем огребать все прелести.
M>А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"?
Кто сказал, что пустой список -- это синглтон? Я бы его назвал синглтоном с большой натяжкой. Вообще-то синглтон, это класс, которой кроме своих прямых обязанностей отвечает за то, чтобы иметь не более одного своего экземпляра. Для этого синглтон как правило имеет приватный (или protected) конструктор (чтобы никто не мог, кроме самого класса синглтона, его создать) и фабричный метод getInstance (чтобы пользователи этого класса могли все таки получить его экземпляр).
List.Nil это, скорее всего, экземпляр класса List. Может быть особый, но отнюдь не единственный: может быть ведь несколько списков, не так ли? Кроме того, что такое совершенно невообразимо плохое может случаится, если будет несколько "пустых" экземпляров списка? Как по мне -- ничего (разве что памяти будет чуть-чуть больше использоваться). А вот для синглтона важно всеми силами предотвратить создание нескольких экземпляров.
--
Дмитро
Re[2]: класс Singleton - разобрался, но где в "жизни" примен
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
А>>А вот для каких жизненных ситуаций может быть использован Singleton ? WH>Ни для каких. WH>Синглетон это антипаттерн. WH>Исплльзование синглитона ничем не отличается от использвания глобальных переменных. WH>И то и другое очень сильно повышает связанность программы.
Только не связанность, а зацепление
лэт ми спик фром май харт
Re[6]: класс Singleton - разобрался, но где в "жизни" примен
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Nicht, Вы писали:
N>>Это ты, извини, о чем?
M>Я же написал — о шаблонах. M>Шаблон — это "стандартное решение". Есть проблема, есть решение, стандартное, проверенное не один раз, и найденное достаточно удачным для решения этой проблемы. M>Конечно, если впихнуть это стандартное решение одной проблемы как решение для другой проблемы — то выйдет фигня. M>Конечно, ещё лучше — знать все шаблонные решения (иначе будет изобретение велосипедов), а вот конкретную проблему решать не шаблонно, а придумать ей новое решение, наиболее удачное. Это тяжело и не всегда удаётся — придумать хорошее решение — поэтому народу так нравятся шаблонные решения и шаблонный способ мышления — в случае чего можно показать книжку "паттерны проектирования" и сказать, что там так написано. Именно поэтому данное направление стало таким модным — оно позволяет снять с себя ответственность, и вообще думать поменьше.
Я еще не видел ни одного человека, который бы использовал шаблоны таким образом. Шаблоны слишком примитивны, чтобы избавлять от необходимости думать. А вот для чего ИМХО они реально применяются — как средство общения. То есть скажешь в документации, или в курилке, или еще где-нить: "фасад" (например) — всем все понятно, что ты имеешь ввиду и не надо пол часа разжевывать.
лэт ми спик фром май харт
Re[11]: класс Singleton - разобрался, но где в "жизни" приме
Здравствуйте, mkizub, Вы писали:
M>Кроме плохого, в глобальных переменных есть и хорошее. Небольшая программа с использованием глобальных переменных — скорее всего будет проще, понятней и эффективней, по сравнению с попыткой написать её-же без глобальных переменных.
С чего бы это?
M>Вот в большом проекте — там да, критическая масса сложности нарастает, и в какой-то момент статические переменные становятся больше злом, чем помощью. Но ведь они, т.е. "паттерн статических переменных" в этом не виноваты, в том, что их продолжают использовать в большом проекте.
В больших проектах зло от статических переменных проявляется с бОльшей силой.
M>Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п. — это ровно то-же, что "предварительная оптимизация".
А в чем конкретно усложнение?
лэт ми спик фром май харт
Re[2]: класс Singleton - разобрался, но где в "жизни" примен
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, <Аноним>, Вы писали:
R>Забавна сама постановка вопроса темы. Шаблон нужно применять только тогда, когда горький или не очень опыт собственных проб и ошибок приведет к осознанию потребности в некотором решении, один из вариантов которого может предложить данный шаблон.
А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет
лэт ми спик фром май харт
Re[10]: класс Singleton - разобрался, но где в "жизни" приме
Здравствуйте, Nicht, Вы писали:
N>Опять же про IoC я написал как наиболее простой пример правильного подхода к синглтону. Синглтон не антипаттерн, до тех пор, пока он не используется как глобальная переменная. Стоит только поразбрасать по коду Singleton.getInstance(), тут мы и начинаем огребать все прелести.
Так глобальная точка доступа и есть одно из свойств синглетона. И если ее не использовать то это уже будет не синглетон, а просто объект который на данном этапе живет в одном экземпляре.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: класс Singleton - разобрался, но где в "жизни" примен
Здравствуйте, Nicht, Вы писали:
N>И вот тогда появляется Inversion of Control. Тогда вся логика создания объектов выносится в контекст приложения, а само приложение уже не волнуется о том, синглтон какой то конкретный класс, или нет. Такой подход и масштабируется лучше, и поддерживается легче.
Давай не путать синглетон и объект живущей в одном экземпляре.
Это сильно разные вещь.
IOC какраз используется для того чтобы мысль о синглитонах даже не возникала.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: класс Singleton - разобрался, но где в "жизни" примен
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Контрпримеры: LCR>1. System.in, System.out, System.err — у кого с ними проблемы?
Несколько раз нарывался на то что нужно было переводить вывод в консоль на вывод в файл.
Еслибы сразу воткнул поток то этого бы не понадобилось. Просто бы сменил один поток на другой.
Да чуть не забыл... потом этот код вполне может уехать в многопоточное окружение...
LCR>Здесь 7 синглтонов под одной крышей. Почему никому не приходит в голову завести два понедельника!!!? Можно продолжать в том же духе для типизированных конфигов всевозможного вида.
Тут какраз тот случай когда по уму у дней недели вобще не должно быть identity но мегаархитекторы жабы не предусмотрели value типы.
LCR>и аналогичный подход на Йаве. Указанным свойством (трудность замены реализации) обладают прибитые гвоздями статические переменные. Но у них есть преимущество в том, что очень легко оформить это решение и решение (паттерн) легко узнаваем.
А если нам нужно не просто заменить но держать несколько экземпляров?
Причем в разных контекстах разные?
Вот например задачка:
Есть сервер с кучей сессий.
В начали его разработки туда добавили логгер и сделали его синглетоном.
А что? Удобно. Где угодно взял и что угодно вывел в лог.
Наколбасили несколько метров кода.
А потом вдруг подумали что не плохо былобы в лог писать ID сессии ибо иначе под нагрузкой он становится не информативным тк сотня сессий смешиваются так что становится ничего не понятно.
А еще неплохо было бы иметь для разных сессий разный уровень логирования.
Что делать будешь?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: класс Singleton - разобрался, но где в "жизни" приме
Здравствуйте, mkizub, Вы писали:
M>А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"? Впрочем, про true и false я уже приводил примеры. Тоже — уникальные, глобальные и всё такое.
У них нет identity!
M>Кроме плохого, в глобальных переменных есть и хорошее. Небольшая программа с использованием глобальных переменных — скорее всего будет проще, понятней и эффективней, по сравнению с попыткой написать её-же без глобальных переменных.
Про эффективней просто не правда.
Понятней может быть только ну очень маленькая программка. И то врядли.
Строк 100 не больше.
Дальше уже нужно нормально структуировать иначе звиздец.
А если учесть что программы имеют тенденцию разростаться...
Короче глобальные переменные подходят только для случаев когда код однозначно одноразовый.
M>Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п.
За последние несколько лет я написал всего один goto по делу и еще два по приколу. А если бы у меня были локальные функции с гарантированной раскруткой хвостовой рекурсии то я вобще ни одного бы не написал.
С глобальными переменными таже фигня.
Если научится писать без них то они становятся просто не нужны.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: класс Singleton - разобрался, но где в "жизни" примен
Здравствуйте, WolfHound, Вы писали:
WH>Вот например задачка: WH>Есть сервер с кучей сессий. WH>В начали его разработки туда добавили логгер и сделали его синглетоном. WH>А что? Удобно. Где угодно взял и что угодно вывел в лог. WH>Наколбасили несколько метров кода. WH>А потом вдруг подумали что не плохо былобы в лог писать ID сессии ибо иначе под нагрузкой он становится не информативным тк сотня сессий смешиваются так что становится ничего не понятно. WH>А еще неплохо было бы иметь для разных сессий разный уровень логирования.
WH>Что делать будешь?
Переписывать.
Зато у них есть работающая программа.
Если бы они сразу в неё попытались впихнуть всё заранее — то работающей программы у них бы не было.
Preliminary optimization за что ругают?
90% программ не испытывают проблем со стандартным потоком вывода. 9 из оставшихся 10 — решают эту проблему на уровне batch файла
или библиотек (которые такую возможность чаще всего дают).
Начинать писать программу предусматривая, что может быть понадобится перенаправление в файл, да ещё сильно нестандартное перенаправление — это не самое удачное решение.
Здравствуйте, prVovik, Вы писали:
V>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет
Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.
