Re[28]: класс Singleton - разобрался, но где в "жизни" приме - Компьютерные священные войны

Аноним,

А>или по- ученому он называется "дизайн паттерн" — тоже не знаю как просто это назвать
А>но главное в каких целях это можно использовать?
А>Вот скажем JFile — для манипуляций с файлами. JButton — понятно зачем.
А>А вот для каких жизненных ситуаций может быть использован Singleton ?

Когда произносишь слово "паттерн" — главное не надо морщить лоб и делать серьёзный вид — в паттернах нет чего-то сверхособенного

. Для ООП паттерн — это просто класс или группа классов с определёнными ограничениями на интерфейс и поведение (эти ограничения обычно отражаются в названии паттерна).

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

Например, синглтоном может быть пул потоков, коннекшнов или ещё чего-нибудь. Если по логике приложения допустимо иметь несколько пулов, тогда менеджер пулов логично сделать синглтоном. Например, можно посмотреть LogManager.repositorySelector в библиотеке Log4j.

Фабрики можно сделать синглтоном. Если допустимы несколько фабрик, тогда объект, который управляет фабриками логично сделать синглтоном.

Некоторый объект-коллекция, который поддерживает рабочие объекты в актуальном состоянии (см. publish-subscribe). Этот объект-коллекция должен иметь доступ к рабочим объектам чтобы в нужный момент разослать им нужные сообщения. Значит его логично сделать синглтоном, чтобы из различных мест программы иметь возможность добавлять/удалять элементы из коллекции. Если допустимо иметь несколько таких объектов-коллеций, тогда объект-контейнер коллекций логично сделать синглтоном.

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

Здравствуйте, <Аноним>, Вы писали:

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Например, синглтоном может быть пул потоков, коннекшнов или ещё чего-нибудь. Если по логике приложения допустимо иметь несколько пулов, тогда менеджер пулов логично сделать синглтоном. Например, можно посмотреть LogManager.repositorySelector в библиотеке Log4j.
А если допустимо несколько менеджеров пулов потоков?
А если в начале разработки оно было не надо, а потом понадобилось?

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, WolfHound, Вы писали:

WH>Что бы там не говорили про инкапсуляцию и прочие типа преимущества синглитона перед глобальной переменной главная проблема остается.

В чём же проблема? true и false, как перечислимые глобальные значения — для тебя тоже проблема?
Класс String (или любой другой) как глобальный уникальный объект — это тоже проблема?

Здравствуйте, mkizub, Вы писали:

M>В чём же проблема? true и false, как перечислимые глобальные значения — для тебя тоже проблема?
M>Класс String (или любой другой) как глобальный уникальный объект — это тоже проблема?
Если нет identity то и проблемы нет.
Но как только появляется объект с identity (объектов без identity вобще говоря не бывает) и глобальной точкой доступа. Все. Тушите свет.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, mkizub, Вы писали:

M>>В чём же проблема? true и false, как перечислимые глобальные значения — для тебя тоже проблема?
M>>Класс String (или любой другой) как глобальный уникальный объект — это тоже проблема?
WH>Если нет identity то и проблемы нет.
WH>Но как только появляется объект с identity (объектов без identity вобще говоря не бывает) и глобальной точкой доступа. Все. Тушите свет.

брр.. Ваше предложение?

Здравствуйте, pvnic, Вы писали:

P>брр.. Ваше предложение?

И вот тогда появляется Inversion of Control. Тогда вся логика создания объектов выносится в контекст приложения, а само приложение уже не волнуется о том, синглтон какой то конкретный класс, или нет. Такой подход и масштабируется лучше, и поддерживается легче.

WolfHound,

LCR>>Например, синглтоном может быть пул потоков, коннекшнов или ещё чего-нибудь. Если по логике приложения допустимо иметь несколько пулов, тогда менеджер пулов логично сделать синглтоном. Например, можно посмотреть LogManager.repositorySelector в библиотеке Log4j.

WH>А если допустимо несколько менеджеров пулов потоков?
По индукции...

WH>А если в начале разработки оно было не надо, а потом понадобилось?
Делаешь конструктор пабликом, объявляешь getInstance депрекейтед, подробно комментируешь сиё решение. В следующей версии грохаешь этот метод. Обычное эволюционирование ПО, неразрешимых проблем не вижу в упор... Или у нас при изменении требований запрещено менять исходный код?

Ещё раз.

Синглтон — это способ вынести ограничение "один и только один объект" (что часто пересекается с ограничением "сделать инициализацию один и только один раз в самом начале") в библиотечный код. У этого паттерна ессно есть недостатки, и когда они критичны, то перекладывают соблюдение этого ограничения на юзера.

Вместо того, чтобы оголтело кидаться с шашкой на синглтоны, лучше напиши, как сделать так, чтобы некоторый метод initialize был бы вызван один и только один раз перед запуском других зависимостей, и это гарантировалось бы компилятором? В самой что ни на есть обычной Йаве, где нет ни макросов (кстати, сомневаюсь, что они здесь помогут), ни dependent types, ни прочих megarulez-ов.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>WolfHound,

LCR>>>Например, синглтоном может быть пул потоков, коннекшнов или ещё чего-нибудь. Если по логике приложения допустимо иметь несколько пулов, тогда менеджер пулов логично сделать синглтоном. Например, можно посмотреть LogManager.repositorySelector в библиотеке Log4j.

WH>>А если допустимо несколько менеджеров пулов потоков?
LCR>По индукции...

WH>>А если в начале разработки оно было не надо, а потом понадобилось?
LCR>Делаешь конструктор пабликом, объявляешь getInstance депрекейтед, подробно комментируешь сиё решение. В следующей версии грохаешь этот метод. Обычное эволюционирование ПО, неразрешимых проблем не вижу в упор... Или у нас при изменении требований запрещено менять исходный код?

Избавление от singleton'а, конечно, не относится к классу Неразрешимых проблем.

Однако, это может стать трудноразрешимой проблемой. По коду может быть разбросаны сотни ThreadPool.getInstance(), которые придется поменять.

LCR>Синглтон — это способ вынести ограничение "один и только один объект" (что часто пересекается с ограничением "сделать инициализацию один и только один раз в самом начале") в библиотечный код.

Я говорю, конечно, опираясь на свой опыт, но мне не часто встречались ситуации, когда ограничение "один и только один объект" было бы критичным. Это ограничение может быть связано с низкоуровневыми ресурсами, да и то: у приложения может быть несколько top-level окон (хотя обычно только одно), на машине может быть несколько процессоров (хотя обычно один), несколько сетевых карт (хотя обычно одна), несколько видеокарт (хотя обычно одна), а с видеокартой может быть связано несколько дисплеев (хотя обычно один). Синглтон часто используют как глобальную переменную, к которой можно доступиться из любой части программы. И именно этот вариант использования является миной замедленного действия. Кстати, код, в котором активно используются сингтоны, юниттестировать обычно весьма и весьма сложно (из-за того, что приходися извращаться для того, чтобы заменить реализацию синглтона).

Здравствуйте, Nicht, Вы писали:

N>И вот тогда появляется Inversion of Control.

Маразм крепчал.
Buzz-words и hype на марше.

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

Дмитрий,

А что же ты самое интересное-то выпустил?

LCR>>Вместо того, чтобы оголтело кидаться с шашкой на синглтоны, лучше напиши, как сделать так, чтобы некоторый метод initialize был бы вызван один и только один раз перед запуском других зависимостей, и это гарантировалось бы компилятором? В самой что ни на есть обычной Йаве, где нет ни макросов (кстати, сомневаюсь, что они здесь помогут), ни dependent types, ни прочих megarulez-ов.

Ниже можешь не читать, это я просто для продолжения разговора

D>Избавление от singleton'а, конечно, не относится к классу Неразрешимых проблем.

Однако, это может стать трудноразрешимой проблемой. По коду может быть разбросаны сотни ThreadPool.getInstance(), которые придется поменять.

Да, согласен, потребуется определённая работа. ThreadPool.getInstance() поменять на threadPool, и затем воспользоваться какой-нибудь техникой инжектить эту зависимость. Причём уже нужно смотреть в оба, чтобы случайно не заинжектить пустой объект или нуль, или объект в промежуточном (обычно некорректном) состоянии. Говоря совсем заумно, программист-пользователь ThreadPool должен вручную реализовать транзитивное замыкание графа зависимостей от объекта threadPool. Код становится более модульным и всё-такое, но и более сложным — трейдофф налицо.

LCR>>Синглтон — это способ вынести ограничение "один и только один объект" (что часто пересекается с ограничением "сделать инициализацию один и только один раз в самом начале") в библиотечный код.

D>Я говорю, конечно, опираясь на свой опыт, но мне не часто встречались ситуации, когда ограничение "один и только один объект" было бы критичным. Это ограничение может быть связано с низкоуровневыми ресурсами, да и то: у приложения может быть несколько top-level окон (хотя обычно только одно), на машине может быть несколько процессоров (хотя обычно один), несколько сетевых карт (хотя обычно одна), несколько видеокарт (хотя обычно одна), а с видеокартой может быть связано несколько дисплеев (хотя обычно один). Синглтон часто используют как глобальную переменную, к которой можно доступиться из любой части программы. И именно этот вариант использования является миной замедленного действия.

Контрпримеры:
1. System.in, System.out, System.err — у кого с ними проблемы?
2. LogManager.repositorySelector в библиотеке Log4j,
3. Handler.INSTANCE и Launcher в библиотеке classworlds,
4. public static final String NEWLINE = System.getProperty("line.separator");
5. public static final String VERSION = "2.3b10"; // а могло быть запросто быть объектом типа Version
6. public static ErrorListener DEFAULT_ERROR_LISTENER = ... bla-bla-bla ...
7. Ещё характерные для Йавы 1.4

class WeekDay {
  public static final WeekDay MONDAY = new WeekDay();
  ...
  public static final WeekDay SUNDAY = new WeekDay();
}

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

Коли ты завёл разговор про дисплеи и окна, вот тебе мой ответ Чемберлену на равно отвлечённую тему:
Земля у тебя одна, ты — один, Солнце — одно, небо — тоже чёрт возьми одно, Вселенная — одна (мы можем запросто принять эту гипотезу за истину ибо мы не можем ни доказать ни опровергнуть её), атом водорода — один, десятичное представление числа — одно, разложение вектора по единичным векторам — одно, метрика в метрическом пространстве — одна, нормальная форма лямбда-функции — одна. Продолжать?

D>Кстати, код, в котором активно используются сингтоны, юниттестировать обычно весьма и весьма сложно (из-за того, что приходися извращаться для того, чтобы заменить реализацию синглтона).

Ну так тебе просто нужны правильные синглтоны:

object Or extends Join {
  def apply(b1: => boolean, b2: => boolean): boolean = {
    concurrent.ops.spawn(res1(res1.C(b1)));
    concurrent.ops.spawn(res2(res2.C(b2)));
    res(res.C())
  }
}

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

Здравствуйте, mkizub, Вы писали:

M>Маразм крепчал.
M>Buzz-words и hype на марше.

M>Ребята, вы простую вещь поймите. Всего надо в меру.
M>А эти священные войны и объявления войны всему по очереди, доведение хороших идей до полного маразма — это удел нищих разумом.
M>Спор, какое из шаблонных решений лучше — не имеет смысла по той простой причине, что это шаблонные решения.

Это ты, извини, о чем?
Singleton и IoC это совершенно параллельные вещи. Просто pvnic спросил что делать с синглтоном в случае описанном WolfHound.
Своим постом я и хотел сказать, что глупое втыкание синглтона в код, это решение дурнопахнущее, а вот если сиглтон используется внутри IoC контекста, но это совсем другое дело, тогда это действительно один объект на приложение, а не глобальная переменная.

Здравствуйте, Nicht, Вы писали:

N>Это ты, извини, о чем?

Я же написал — о шаблонах.
Шаблон — это "стандартное решение". Есть проблема, есть решение, стандартное, проверенное не один раз, и найденное достаточно удачным для решения этой проблемы.
Конечно, если впихнуть это стандартное решение одной проблемы как решение для другой проблемы — то выйдет фигня.
Конечно, ещё лучше — знать все шаблонные решения (иначе будет изобретение велосипедов), а вот конкретную проблему решать не шаблонно, а придумать ей новое решение, наиболее удачное. Это тяжело и не всегда удаётся — придумать хорошее решение — поэтому народу так нравятся шаблонные решения и шаблонный способ мышления — в случае чего можно показать книжку "паттерны проектирования" и сказать, что там так написано. Именно поэтому данное направление стало таким модным — оно позволяет снять с себя ответственность, и вообще думать поменьше.

А что в этой дискуссии? Один вычитал про Singleton, и теперь озабочен — как бы ему это сокровенное знание применить. Другие читали другие книжки, где наглядно доказывается, что применение шаблонных решений необдуманно — ведёт к хреновым результатам. И спешат поделится этим сокровенным знанием, и волшебным словом "антипаттерн".

Третьи (извини, в твой огород камень) рассказывают, что есть некий идеальный шаблон IoC (тоже замечательное шаблонное решение — но для решения очень определённого класса проблем, и не надо его совать в каждую дырку), и вот если его смешать с Singleton, то на последний падёт тень благородства IoC, и он станет не таким плохим. Как вообще можно говорить о применимости или неприменимости какого-то шаблонного решения, если ещё ничего не сказано о самой проблеме? Как только начинаются такие разговоры — то это однозначно дилетантизм, hupe и buzz-words. Обсуждать достоинства и недостатки шаблонных решений безотносительно проблем, которые они призваны решить — это полное непонимание самого понятия, самой сути "шаблонов проектирования".

Здравствуйте, mkizub, Вы писали:

M>Я же написал — о шаблонах.
M>Шаблон — это "стандартное решение". Есть проблема, есть решение, стандартное, проверенное не один раз, и найденное достаточно удачным для решения этой проблемы.
M>Конечно, если впихнуть это стандартное решение одной проблемы как решение для другой проблемы — то выйдет фигня.
M>Конечно, ещё лучше — знать все шаблонные решения (иначе будет изобретение велосипедов), а вот конкретную проблему решать не шаблонно, а придумать ей новое решение, наиболее удачное...

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

M>Это тяжело и не всегда удаётся — придумать хорошее решение — поэтому народу так нравятся шаблонные решения и шаблонный способ мышления — в случае чего можно показать книжку "паттерны проектирования" и сказать, что там так написано. Именно поэтому данное направление стало таким модным — оно позволяет снять с себя ответственность, и вообще думать поменьше.

Это сильно. 'Паттерны фигня, потому что их кто-то другой уже собрал в одном месте, четко сформулировал и выпустил в свет. Поэтому это решение для тех, кто не хочет думать и хочет снять с себя ответственность.'. Два вопроса — назови плз какую-нибудь проблему, решаемую паттерном (возьмем для простоты только GoF паттерны) и объясни, почему это решение плохо, и как бы его улучшить (т.е. 'придумать хорошее нешаблонное решение'). Второй вопрос — много ли ты знаешь людей, которые понимают, что такое и как использовать такие паттерны, как, например, visitor и flyweight?

M>А что в этой дискуссии? Один вычитал про Singleton, и теперь озабочен — как бы ему это сокровенное знание применить. Другие читали другие книжки, где наглядно доказывается, что применение шаблонных решений необдуманно — ведёт к хреновым результатам. И спешат поделится этим сокровенным знанием, и волшебным словом "антипаттерн".

M>Третьи (извини, в твой огород камень) рассказывают, что есть некий идеальный шаблон IoC (тоже замечательное шаблонное решение — но для решения очень определённого класса проблем, и не надо его совать в каждую дырку), и вот если его смешать с Singleton, то на последний падёт тень благородства IoC, и он станет не таким плохим. Как вообще можно говорить о применимости или неприменимости какого-то шаблонного решения, если ещё ничего не сказано о самой проблеме? Как только начинаются такие разговоры — то это однозначно дилетантизм, hupe и buzz-words. Обсуждать достоинства и недостатки шаблонных решений безотносительно проблем, которые они призваны решить — это полное непонимание самого понятия, самой сути "шаблонов проектирования".

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

Здравствуйте, mkizub, Вы писали:

M>А что в этой дискуссии? Один вычитал про Singleton, и теперь озабочен — как бы ему это сокровенное знание применить. Другие читали другие книжки, где наглядно доказывается, что применение шаблонных решений необдуманно — ведёт к хреновым результатам. И спешат поделится этим сокровенным знанием, и волшебным словом "антипаттерн".

M>Третьи (извини, в твой огород камень) рассказывают, что есть некий идеальный шаблон IoC...

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

Ты уверен, что для того, чтобы быть услышанным, необходимо настраивать против себя весь свет?

Здравствуйте, bolshik, Вы писали:

M>>Конечно, ещё лучше — знать все шаблонные решения (иначе будет изобретение велосипедов), а вот конкретную проблему решать не шаблонно, а придумать ей новое решение, наиболее удачное...

B>Зачастую большую проблему можно хорошо декомпозировать, по твоей логике получается, что для решения полученных маленьких проблем не следует использовать паттерны (потому что это шаблонно), а надо придумать что-то свое?

А про ненужность изобретения велосипедов я не писал?

M>>Это тяжело и не всегда удаётся — придумать хорошее решение — поэтому народу так нравятся шаблонные решения и шаблонный способ мышления — в случае чего можно показать книжку "паттерны проектирования" и сказать, что там так написано. Именно поэтому данное направление стало таким модным — оно позволяет снять с себя ответственность, и вообще думать поменьше.

B>Это сильно. 'Паттерны фигня, потому что их кто-то другой уже собрал в одном месте, четко сформулировал и выпустил в свет. Поэтому это решение для тех, кто не хочет думать и хочет снять с себя ответственность.'. Два вопроса — назови плз какую-нибудь проблему, решаемую паттерном (возьмем для простоты только GoF паттерны) и объясни, почему это решение плохо, и как бы его улучшить (т.е. 'придумать хорошее нешаблонное решение'). Второй вопрос — много ли ты знаешь людей, которые понимают, что такое и как использовать такие паттерны, как, например, visitor и flyweight?

GoF не читал. flyweight — не слышал о таком.
visitor — это чаще всего от бедности и неимения multimethods. Кроме того, буквально два дня назад читал список вариаций шаблона visitor — их чуть меньше десятка. Это ответ на вопрос "как его улучшить".

B>Т.е. это и есть как раз суть паттерна — не придумывать велосипед при решении часто возникающих, хорошо описанных задач, а использовать готовые наработки.

А я именно это самое и написал.

	От:	Аноним
	Дата:	20.07.07 21:29
	Оценка:

	От:	Аноним
	Дата:	20.07.07 23:29
	Оценка:

	От:	Аноним
	Дата:	21.07.07 02:27
	Оценка:

	От:	-Genius-
	Дата:	21.07.07 04:02
	Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	21.07.07 09:53
Оценка:	+3

	От:	WolfHound
	Дата:	22.07.07 11:42
	Оценка:	3 (3) +5 -5

От:	mkizub	http://symade.tigris.org
Дата:	22.07.07 19:23
Оценка:

От:	bolshik	http://denis-zhdanov.blogspot.com/
Дата:	24.07.07 04:53
Оценка:

	От:	Nicht
	Дата:	23.07.07 06:49
	Оценка:	1 (1) +1

	От:	dshe
	Дата:	23.07.07 11:53
	Оценка:	+3

	От:	Nicht
	Дата:	23.07.07 15:05
	Оценка:	+2