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

примеров не было разве? в чем же тогда разбирался, в приватном конструкторе, в static переменной и в static getInstance()?

Здравствуйте, Аноним, Вы писали:
Выходит что да! А в чем еще ? Вот и спрашиваю почему же назвали гордо "design pattern" ?
И где ( с чем) его едять?
примеры были простенькие — а где "в жизни" применяют не понял? сорри — ну непонятливый мы!

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

А>Выходит что да! А в чем еще ? Вот и спрашиваю почему же назвали гордо "design pattern" ?
А>И где ( с чем) его едять?
А>примеры были простенькие — а где "в жизни" применяют не понял? сорри — ну непонятливый мы!

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

Более приближенный к жизни пример — т.н. класс "умных ссылок", которые работают через класс-менеджер. Именно этот класс-менеджер может быть Singleton.

Если есть желание узнать больше по паттернам проектирования — есть книга

Э.Гамма, Р.Хелм, Р.Джонсон, Дж.Влиссидес

Приемы объектно-ориентированного проектирования. Паттерны проектирования

Серия: Библиотека программиста

Аноним,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Т.е. это и есть как раз суть паттерна — не придумывать велосипед при решении часто возникающих, хорошо описанных задач, а использовать готовые наработки.

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

Здравствуйте, 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>Собственно, опять к тому-же и пришли — говорить о хорошести и плохости шаблона — бессмысленно, без знания задачи, которую нужно решить.

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

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

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

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

M>Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п. — это ровно то-же, что "предварительная оптимизация".
Тонны процедурного кода очень сложно оптимизировать до соответствия объектному подходу.

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

Забавна сама постановка вопроса темы. Шаблон нужно применять только тогда, когда горький или не очень опыт собственных проб и ошибок приведет к осознанию потребности в некотором решении, один из вариантов которого может предложить данный шаблон. Именно тогда разработчик применит шаблон в соответствии с его назначением, а к примеру, не будет компенсировать кривой дизайн системы посредством создания глобальных переменных, опошляя идею шаблона Одиночка — опять же потому что незнаком с другими типовыми решениями, посредством применения которых можно обойтись и без глобальной связности всего кода, или попросту не видит область их применения в своей задаче.

Несмотря на то, что в GoF-ы достаточно подробно описывают область применения, полезность, выгоду и etc бонусы — каждого рассматренного паттерна, без опыта работы с кодом, который они описывают, "крутость" шаблонов будет непонятна.

PS Уже как-то ворчал по этому поводу: Re[2]: Обобщенный Model-View-Controller

Автор: rsn81
Дата: 29.03.07

.

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

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

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

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

N>>Синглтон не антипаттерн, до тех пор, пока он не используется как глобальная переменная. Стоит только поразбрасать по коду Singleton.getInstance(), тут мы и начинаем огребать все прелести.

M>А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"?

Кто сказал, что пустой список -- это синглтон? Я бы его назвал синглтоном с большой натяжкой. Вообще-то синглтон, это класс, которой кроме своих прямых обязанностей отвечает за то, чтобы иметь не более одного своего экземпляра. Для этого синглтон как правило имеет приватный (или protected) конструктор (чтобы никто не мог, кроме самого класса синглтона, его создать) и фабричный метод getInstance (чтобы пользователи этого класса могли все таки получить его экземпляр).

List.Nil это, скорее всего, экземпляр класса List. Может быть особый, но отнюдь не единственный: может быть ведь несколько списков, не так ли? Кроме того, что такое совершенно невообразимо плохое может случаится, если будет несколько "пустых" экземпляров списка? Как по мне -- ничего (разве что памяти будет чуть-чуть больше использоваться). А вот для синглтона важно всеми силами предотвратить создание нескольких экземпляров.

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

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

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

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

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

А можно в двух словах, что это такое, читал Wikipedia, не очень хорошо понял.

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

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

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

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

Я еще не видел ни одного человека, который бы использовал шаблоны таким образом. Шаблоны слишком примитивны, чтобы избавлять от необходимости думать. А вот для чего ИМХО они реально применяются — как средство общения. То есть скажешь в документации, или в курилке, или еще где-нить: "фасад" (например) — всем все понятно, что ты имеешь ввиду и не надо пол часа разжевывать.

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

M>Кроме плохого, в глобальных переменных есть и хорошее. Небольшая программа с использованием глобальных переменных — скорее всего будет проще, понятней и эффективней, по сравнению с попыткой написать её-же без глобальных переменных.
С чего бы это?

M>Вот в большом проекте — там да, критическая масса сложности нарастает, и в какой-то момент статические переменные становятся больше злом, чем помощью. Но ведь они, т.е. "паттерн статических переменных" в этом не виноваты, в том, что их продолжают использовать в большом проекте.

В больших проектах зло от статических переменных проявляется с бОльшей силой.

M>Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п. — это ровно то-же, что "предварительная оптимизация".
А в чем конкретно усложнение?

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

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

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

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

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

N>Опять же про IoC я написал как наиболее простой пример правильного подхода к синглтону. Синглтон не антипаттерн, до тех пор, пока он не используется как глобальная переменная. Стоит только поразбрасать по коду Singleton.getInstance(), тут мы и начинаем огребать все прелести.
Так глобальная точка доступа и есть одно из свойств синглетона. И если ее не использовать то это уже будет не синглетон, а просто объект который на данном этапе живет в одном экземпляре.

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

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

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

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

LCR>Контрпримеры:
LCR>1. System.in, System.out, System.err — у кого с ними проблемы?
Несколько раз нарывался на то что нужно было переводить вывод в консоль на вывод в файл.
Еслибы сразу воткнул поток то этого бы не понадобилось. Просто бы сменил один поток на другой.
Да чуть не забыл... потом этот код вполне может уехать в многопоточное окружение...

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

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

Вот например задачка:
Есть сервер с кучей сессий.
В начали его разработки туда добавили логгер и сделали его синглетоном.
А что? Удобно. Где угодно взял и что угодно вывел в лог.
Наколбасили несколько метров кода.
А потом вдруг подумали что не плохо былобы в лог писать ID сессии ибо иначе под нагрузкой он становится не информативным тк сотня сессий смешиваются так что становится ничего не понятно.
А еще неплохо было бы иметь для разных сессий разный уровень логирования.

Что делать будешь?

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

M>А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"? Впрочем, про true и false я уже приводил примеры. Тоже — уникальные, глобальные и всё такое.
У них нет identity!

M>Кроме плохого, в глобальных переменных есть и хорошее. Небольшая программа с использованием глобальных переменных — скорее всего будет проще, понятней и эффективней, по сравнению с попыткой написать её-же без глобальных переменных.
Про эффективней просто не правда.
Понятней может быть только ну очень маленькая программка. И то врядли.
Строк 100 не больше.
Дальше уже нужно нормально структуировать иначе звиздец.
А если учесть что программы имеют тенденцию разростаться...

Короче глобальные переменные подходят только для случаев когда код однозначно одноразовый.

M>Заранее усложнять программу, до того как она написана, из одних только побуждений "глобальные переменные — это зло", или "goto — это зло" и т.п.
За последние несколько лет я написал всего один goto по делу и еще два по приколу. А если бы у меня были локальные функции с гарантированной раскруткой хвостовой рекурсии то я вобще ни одного бы не написал.
С глобальными переменными таже фигня.
Если научится писать без них то они становятся просто не нужны.

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

WH>Вот например задачка:
WH>Есть сервер с кучей сессий.
WH>В начали его разработки туда добавили логгер и сделали его синглетоном.
WH>А что? Удобно. Где угодно взял и что угодно вывел в лог.
WH>Наколбасили несколько метров кода.
WH>А потом вдруг подумали что не плохо былобы в лог писать ID сессии ибо иначе под нагрузкой он становится не информативным тк сотня сессий смешиваются так что становится ничего не понятно.
WH>А еще неплохо было бы иметь для разных сессий разный уровень логирования.

WH>Что делать будешь?

Переписывать.
Зато у них есть работающая программа.
Если бы они сразу в неё попытались впихнуть всё заранее — то работающей программы у них бы не было.
Preliminary optimization за что ругают?

90% программ не испытывают проблем со стандартным потоком вывода. 9 из оставшихся 10 — решают эту проблему на уровне batch файла
или библиотек (которые такую возможность чаще всего дают).
Начинать писать программу предусматривая, что может быть понадобится перенаправление в файл, да ещё сильно нестандартное перенаправление — это не самое удачное решение.

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

V>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет

Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

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

M>Переписывать.
M>Зато у них есть работающая программа.
M>Если бы они сразу в неё попытались впихнуть всё заранее — то работающей программы у них бы не было.
M>Preliminary optimization за что ругают?

M>90% программ не испытывают проблем со стандартным потоком вывода. 9 из оставшихся 10 — решают эту проблему на уровне batch файла
M>или библиотек (которые такую возможность чаще всего дают).
M>Начинать писать программу предусматривая, что может быть понадобится перенаправление в файл, да ещё сильно нестандартное перенаправление — это не самое удачное решение.

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

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

M>>А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"? Впрочем, про true и false я уже приводил примеры. Тоже — уникальные, глобальные и всё такое.
WH>У них нет identity!

Куда делась?

WH>Про эффективней просто не правда.

У нас разный опыт.

WH>За последние несколько лет я написал всего один goto по делу и еще два по приколу. А если бы у меня были локальные функции с гарантированной раскруткой хвостовой рекурсии то я вобще ни одного бы не написал.

И что? А я больше раз. По делу.

WH>С глобальными переменными таже фигня.
WH>Если научится писать без них то они становятся просто не нужны.

Можно, но не нужно. Можно носить с собой контекст в параметре каждого метода, можно ложить контекст в локальную переменную треда, много ещё чего можно. Но не нужно. А если понадобится — то недолго переделать.

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

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

V>>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет

M>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

Жить в одном экземпляре и синглтон — это не одно и тоже. Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом). Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

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

M>Переписывать.
Несколько метров кода?
Круто!

M>Зато у них есть работающая программа.
Нет у них работающий программы.
Они из нее тараканов выловить не могут. Ибо в логах чехорда.
И исправить это быстро невозможно.

M>Если бы они сразу в неё попытались впихнуть всё заранее — то работающей программы у них бы не было.
Не нужно впихнуть все. Нужно не забывать о том что код придется поддерживать. И всеми силами стремится к тому чтобы поддерживать его было легко.
Синглетоны заведомо осложняют поддержку. Причем всегда и сильно.

M>Preliminary optimization за что ругают?
А что делают за написание заведомо неработоспособных решений?

M>Начинать писать программу предусматривая, что может быть понадобится перенаправление в файл, да ещё сильно нестандартное перенаправление — это не самое удачное решение.
Блин. Просто афигенное усложнение...
Вместо:

void generate()
{
    ...
    std::cout << "bla-bla";
    ...
}

int main()
{
    generate();
}

пишем:

void generate(std::ostream& out)
{
    ...
    out << "bla-bla";
    ...
}

int main()
{
    generate(std::cout);
}

И все! Больше никаких проблем с выводом в файл. Или в поток в памяти.

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

M>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.
А мне очевидно что одним пулом потоков обойтись можно далеко не всегда.
Надеюсь про дедлоки на пулах потоков расказывать не нужно?

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

M>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

V>Жить в одном экземпляре и синглтон — это не одно и тоже.

Конечно это разные вещи. А вот жить гарантированно в одном экземпляре — это одно и то-же.

V>Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом).

То есть ты себе что-то понимаешь, и с этим чем-то споришь.

V>Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

Тем, что есть вещи семантически уникальные. Как только их становится несколько — это нарушение контракта и дизайна.
Чаще всего таких объектов вообще не надо иметь (в смысле — не обязательно их иметь). Раз он один, уникальный, то и не нужен он.
Единственный существующий пул тредов можно заменить набором статических методов и переменных.
List.Nil можно заменить чем-то вроде нулевого указателя и т.д.
А шаблон singleton применяют в случаях, когда дизайн (приложения, библиотеки, метода) требует объекта, инстанса — просто
нужно передать ссылку на объект. Т.е. ограничение языка программирования, его средств. Шаблонные решения потом, зачастую,
входят в сам язык программирования. Скажем, singleton вошёл в Scala как object (в отличие от их class-а).
Вошёл именно потому, что это действительно самантическая и удобная абстракция, а не какой-то buzz-word.

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

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

M>>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

V>>Жить в одном экземпляре и синглтон — это не одно и тоже.

M>Конечно это разные вещи. А вот жить гарантированно в одном экземпляре — это одно и то-же.


V>>Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом).

M>То есть ты себе что-то понимаешь, и с этим чем-то споришь.

V>>Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

M>Тем, что есть вещи семантически уникальные. Как только их становится несколько — это нарушение контракта и дизайна.
M>Чаще всего таких объектов вообще не надо иметь (в смысле — не обязательно их иметь). Раз он один, уникальный, то и не нужен он.
M>Единственный существующий пул тредов можно заменить набором статических методов и переменных.
M>List.Nil можно заменить чем-то вроде нулевого указателя и т.д.
M>А шаблон singleton применяют в случаях, когда дизайн (приложения, библиотеки, метода) требует объекта, инстанса — просто
M>нужно передать ссылку на объект. Т.е. ограничение языка программирования, его средств. Шаблонные решения потом, зачастую,
M>входят в сам язык программирования. Скажем, singleton вошёл в Scala как object (в отличие от их class-а).
M>Вошёл именно потому, что это действительно самантическая и удобная абстракция, а не какой-то buzz-word.

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

Во-вторых, при использовании синглтона делается излишне смелое предположение, что объект обязан быть уникальным во всем мире, в любых условиях и любых вариантах использования. Это черевато граблями. Правильнее вообще не делать предположений об уникальности объекта (99%), а если и делать, то только в _рамках_ некоторого ограниченного контекста (1%).

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

SS>А можно в двух словах, что это такое, читал Wikipedia, не очень хорошо понял.

Это способ построения приложения, в котором логика связывания объектов выносится из этих объектов в отдельные сущности.
Грубо говоря, это некие фабрики, которые не только создают объекты, но и инициализируют одни объекты другими.
Это конечно совсем в двух словах.
Можно почитать в документации по spring framework. Там в первых главах это популярно написано.

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

WH>Давай не путать синглетон и объект живущей в одном экземпляре.
WH>Это сильно разные вещь.

WH>IOC какраз используется для того чтобы мысль о синглитонах даже не возникала.

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

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

V>Жить в одном экземпляре и синглтон — это не одно и тоже.

начит мы говорим о разных вещах.

V> Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом). Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?
Я не готов об этом с вами говорить. Тут недавно пробегали мои мысли по извесным реализациям сингелтонов, если интерессно — поищите.

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

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

M>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.
WH>А мне очевидно что одним пулом потоков обойтись можно далеко не всегда.
Я этого не утверждал.

WH>Надеюсь про дедлоки на пулах потоков расказывать не нужно?
не рассказывай.

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

Востановим ход разговора:
V>>>>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет
M>>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.
WH>>А мне очевидно что одним пулом потоков обойтись можно далеко не всегда.
M>Я этого не утверждал.
Так что-же ты хотел сказать приводя пул потоков как хороший пример синглетона если очевидно что синглитоном его делать нельзя?

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

WH>Так что-же ты хотел сказать приводя пул потоков как хороший пример синглетона если очевидно что синглитоном его делать нельзя?

Очевидно что для эфективности такой объект должен жить в одном экземпляре. Остальное ты сам додумал.

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

M>Очевидно что для эфективности такой объект должен жить в одном экземпляре. Остальное ты сам додумал.
Какой еще один экземпляр?
Какая еще эффективность?
Ты вобще о чем?
С одним пулом в некоторых ситуациях могут быть дедлоки.
А если есть дедлоки то программа не работает.

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

WH>Какой еще один экземпляр?
WH>Какая еще эффективность?
WH>Ты вобще о чем?
WH>С одним пулом в некоторых ситуациях могут быть дедлоки.
WH>А если есть дедлоки то программа не работает.

Могу только рекомендовать сменить имплементацию на коректную.

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

M>Могу только рекомендовать сменить имплементацию на коректную.
Реализацию чего?

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

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

M>>Могу только рекомендовать сменить имплементацию на коректную.
WH>Реализацию чего?

Пула потоков в котором бывают дедлоки.

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

M>Пула потоков в котором бывают дедлоки.

Реализация корректна.
Проблемы с пулами фундаментальны.
Просто сама модель пулов подвержена дедлокам.
Сам поймешь как или таки объяснить?

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

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

M>>Пула потоков в котором бывают дедлоки.
WH>
WH>Реализация корректна.
WH>Проблемы с пулами фундаментальны.
WH>Просто сама модель пулов подвержена дедлокам.
WH>Сам поймешь как или таки объяснить?

Я думаю это проблемы твои персональные. Мне не интерессно, если хочешь об этом поговорить лучше заведи топик новый. Спасибо за понимание.

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

M>Я думаю это проблемы твои персональные.
Как скажите мусье де'Артаньян.

M>Мне не интерессно, если хочешь об этом поговорить лучше заведи топик новый. Спасибо за понимание.
Слив засчитан.

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

V>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет

посмотрите тут
http://www.rsdn.ru/Forum/?mid=2005583

Автор: minorlogic
Дата: 16.07.06

Здравствуйте, Sergei Soloviev, Вы писали:
SS>А можно в двух словах, что это такое, читал Wikipedia, не очень хорошо понял.
Это всё о том, где одни объекты берут другие объекты.
В принципе, когда работает метод какого-то объекта, у него есть доступ вот к чему:
1. К объектам, которые ему передали в параметрах
2. К объектам, ссылки на которые сохранены в полях текущего объекта
3. К глобальным переменным
4. К статическим методам классов (включая конструкторы, т.е. к вновь созданным объектам)

Способ 1 предъявляет меньше всего требований к окружению объекта, но он неудобен тем, что части "окружающей вселенной" приходится протаскивать сквозь весь стек.
IoC — это про замену способов 3 и 4 на 2.
Вот пример:

public int Add(int a, int b)
{
  System.Console.WriteLine("adding {0} and {1}", a, b);
    return a + b;
}

Здесь объект сам решил найти себе консоль и вывести текст в нее (используя статический метод класса Console).
IoC меняет место, где принимается решение о том, какой поток вывода использовать:

public class MyClass
{
  public TextWriter LogOutput
    {
      set { _logOutput = value;}
    }
    
    public int Add(int a, int b)
    {
        _logOutput.WriteLine("adding {0} and {1}", a, b);
        return a + b;
    }
}

Здесь вызывающий код должен заранее позаботиться о том, чтобы выполнить myClass.LogOutput = System.Console.Out.
Это разумный компромисс между передачей System.Console.Out при каждом вызове Add и изначальным вариантом.
Если правильно организовать взаимодействие между классами, то непосредственный клиент класса MyClass даже не обязан знать о том, что нужно выбирать какой-то логгер. (Как это и было в начальном варианте). Экземпляр MyClass мог быть "спущен сверху" этому клиенту уже настроенным.

То есть начинаем мы примерно так:

public class Aggregate
{
  public int CountSum(IEnumerable<int> input)
    {
      int sum=0;
        MyClass adder = new MyClass(); // сами конструируем себе объект
      foreach(int item in input)
          sum = adder.Add(sum, item);
        return sum;
    }
}

а заканчиваем примерно так:

public class Aggregate
{
private MyClass _adder;
public MyClass Adder { set { _adder = value;}}
public int CountSum(IEnumerable<int> input)
{
int sum=0;
foreach(int item in input)
sum = _adder.Add(sum, item);
return sum;
}
}

...

public static void Main()
{
  int[] a  = new int[] {1, 2, 3, 4, 5,};
    MyClass adder = new MyClass();
    adder.LogOutput = System.Console.Out; 
    Aggregate agg = new Aggregate();
    agg.Adder = adder;
    int sum = agg.CountSum(a);
}

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

Потому паттерн и называется "Inversion of Control" — право принятия решений переносится с "исполнителя" на "командира".
В сильно заархитектуренных средах основные строительные классы никогда не обращаются к чужим статик методам и полям, а работают исключительно со своими полями. За инициализацией следит среда, зачастую при помощи файлов конфигурации, так что можно добиться произвольно разнообразного поведения без пересборки программы.

Здравствуйте, minorlogic, Вы писали:
M>Очевидно что для эфективности такой объект должен жить в одном экземпляре. Остальное ты сам додумал.
Гм. А можно развернуть это "очевидное" доказательство?
У меня лично ровно обратное ощущение: одним пулом потоков можно пользоваться ровно до тех пор, пока недостаточная эффективность не приведет к необходимости использовать больше.

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

Как только предположение об одинаковости потоков нарушается, начинаются проблемы. Пример: веб приложение, в котором одна страница генерится быстро, а другая обращается к удаленному серверу. Обращения к странице №1 обрабатываются нашим CPU. В среднем, поток, обрабатывающий запрос к странице №1, занимает 25% CPU. Это означает, что не имеет смысла разрешать запускать более четырех потоков одновременно.
Поток, обрабатывающий страницу №2, большую часть времени спит. В среднем, он занимает 1% СPU. Это означает, что лимит в 4 потока загрузит нашу машину примерно на 4%, остальные запросы будут ждать в очереди. Очевидно, что throughput будет примерно в 25 раз ниже, чем мог бы быть. Лимит в 100 потоков приведет к тому, что одновременно будут обслуживаться слишком много запросов к странице 1, увеличивая response time и опять же снижая throughput.

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

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

З.Ы. В качестве оффтопа, можно пообсуждать возможные реализации пулов ресурсов, способные избегать описанной проблемы даже при единственном экземпляре пула в системе.

Очевидно что 10 пулов с лимитом в 4 потока будут больше простаивать чем 1 пул с лимитом 40. Я не утверждаю что такая ситуация присутствует всегда , вы сами привели яркие примеры не вписывающиеся в эту картину.

Если пул потоков кажется сомнительным кандидатом на сингелтон то могу предложить планировщик задач (алгоритмически вероятно лучше иметь один планировщик).

З.Ы. Можно в имплементации запланировать различные сценарии и поведение с учетом приоритетов и т.п.

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

M>Очевидно что 10 пулов с лимитом в 4 потока будут больше простаивать чем 1 пул с лимитом 40.
1. Очевидно, что это утверждение не имеет никакого отношения к решению, делать ли пул синглтоном. Верно?
2. Предыдущее "очевидное" умозаключение оказалось несовместимым с действительностью. Почему ты думаешь, что это утверждение ждет лучшая судьба?
3. В связи с 1 и 2, предлагаю более тщательно подумать над своими заявлениями. Очевидно, что одно осторожное и верное утверждение лучше, чем десять категоричных и неверных, не так ли?

M>Я не утверждаю что такая ситуация присутствует всегда , вы сами привели яркие примеры не вписывающиеся в эту картину.
В какую картину? Синглтон, простите, это как скрижали — высек в камне и живи с ним. Выковырять синглтон из развитого приложения крайне тяжело. Если он подходит лишь для узкого набора частных случаев применения нашей программы/фреймворка/библиотеки, то может быть сразу реализовать общий случай с произвольным количеством пулов? Ибо сузить его на один экземпляр, если это удобно в данном случае, куда как проще, чем провести обратную операцию.
M>Если пул потоков кажется сомнительным кандидатом на сингелтон то могу предложить планировщик задач (алгоритмически вероятно лучше иметь один планировщик).
Слова "вероятно" здесь, наверное, не вполне уместны. Я как бы ожидаю бесспорности от кандидата в синглтоны. Пул потоков, в каком-то смысле, и есть планировщик задач. Тот планировщик, который в операционке, делает, в общем-то, примерно то же, только на другом уровне, и имеет возможность динамически отбирать ресурсы у задачи до ее окончания.
M>З.Ы. Можно в имплементации запланировать различные сценарии и поведение с учетом приоритетов и т.п.
Можно. Но делать такие заявления лучше с осторожностью.

Вы неверно воспринимаете мои высказывания . В треде просили привести примеры объектов которые могли бы быть оправданными сингелтонами, я это и пытаюсь сделать.

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

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

M>Очевидно что 10 пулов с лимитом в 4 потока будут больше простаивать чем 1 пул с лимитом 40.
Очевидно что поток который простаивает не ест ресурсов. Кроме адресного пространства. А если учесть что 64 бита становится обычным делом... Да и 32х бит тоже хватает на очень большое колличество потоков...

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

M>Если пул потоков кажется сомнительным кандидатом на сингелтон
Он не просто сомнительный.
Это вобще ярчайший пример того что ни в коем случае нельзя делать синглетоном.
Ибо он даст тебе в лоб сразу, а не при поддержке.
Причем не только и не столько тормозами сколько дедлоками.
Хотя производительность тоже важна. Грамотная настройка пулов потоков может поднять производительность системы в десятки, а то и сотни раз плюс обеспечить реактивность (медленные запросы не тормозят быстрые). И все это без переписывания кода. Исключительно правкой конфигов.
А если мы имеем дело с распределенкой то неправильно настроеные пулы могут приводить к распределенным дедлокам (это когда 2 или болие машин лочатся друг на друга). Причем тут даже циклы (машина А спрашивает машину Б, машина Б спрашивает машину А) не нужны.

M>то могу предложить планировщик задач (алгоритмически вероятно лучше иметь один планировщик).
Гм. Вот у меня перед глазами сервачек с сотнями тысяч потоков уровня приложения...
Там есть шедуллер...
Я думаю ты уже догадался что он не синглетон...

M>З.Ы. Можно в имплементации запланировать различные сценарии и поведение с учетом приоритетов и т.п.
Чем слово реализация не устраивает?

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

M>Вы неверно воспринимаете мои высказывания . В треде просили привести примеры объектов которые могли бы быть оправданными сингелтонами, я это и пытаюсь сделать.
Это понятно.
Мне непонятно обоснование ваших примеров. Угадывать за ними какие-то философские корни я вообще даже не собираюсь.

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

Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре

В нем сделано сразу два неправильных утверждения. Поясню еще раз:
1. "для эфективности такой объект должен жить в одном экземпляре" — неправда; для максимальной эффективности нужно отдельно пулить задачи с разными профилями активности
2. "Очевидно что" — неправда; эффективность настолько нетривиально зависит от алгоритмов, что очевидных зависимостей практически нет.

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

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

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

S>

Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре

S>В нем сделано сразу два неправильных утверждения. Поясню еще раз:
S>1. "для эфективности такой объект должен жить в одном экземпляре" — неправда; для максимальной эффективности нужно отдельно пулить задачи с разными профилями активности
Вы рассматриваете часный случай , когда пользователь знает о "профилями активности задачи". Если такая информация есть, то конечно ее можно использовать для улучшения показателей работы пула/пулов. Попробуйте посмотреть на задачу с точки зрения когда про таски для пула вы ничего не знаете одинаково.

S>2. "Очевидно что" — неправда; эффективность настолько нетривиально зависит от алгоритмов, что очевидных зависимостей практически нет.
Если не очевидно предлагаю провести эксперимент с 10 пулами по 4 потока и одним пулом с 40 потоками. Задачи запускаемые на пулах оставте в тесте одинаковыми.

S>Я не понимаю, как при их помощи заведомо неправильных утверждений можно обосновывать применение паттерна Синглтон.
Повторяю в последний раз , я НИГДЕ не обосновывал "применение паттерна Синглтон", это ваша фантазия.

M>> Я не помню случая когда бы мне необходим был сингелтон. Его использование я считаю или пробелом проектирования или банальной нехваткой опыта и попыткой делать код из книги.
S>Тогда вообще непонятно, зачем ты пытаешься защищать синглтон. Или это такой тонкий сарказм — попытка предложить заведомо неверные применения синглтона чтобы его дискредитировать?

См. выше, и не фантазируйте.

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

M>В треде просили привести примеры объектов которые могли бы быть оправданными сингелтонами, я это и пытаюсь сделать.

Вообще-то я просил привести пример, когда синглтон имеет _преимущества_ перед другими решениями (например, перед IoC). В примере с пулом потоков я никаких преимуществ кроме возможного в будущем гемороя не увидел.

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

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

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

V>>Жить в одном экземпляре и синглтон — это не одно и тоже.

M>начит мы говорим о разных вещах.

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

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

V>Только не связанность, а зацепление

http://lingvo.yandex.ru/en?CardId=SY291cGxpbmc,;L0F

coupling

1) связь
2) соединение
3) связывание, увязка
4) связность (модулей системы)

Ваш ход, коллега. Только не надо в качестве аргумента приводить убогий перевод Буча.

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

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

V>>Только не связанность, а зацепление

AVK>http://lingvo.yandex.ru/en?CardId=SY291cGxpbmc,;L0F
AVK>

coupling

AVK>1) связь
AVK>2) соединение
AVK>3) связывание, увязка
AVK>4) связность (модулей системы)

AVK>Ваш ход, коллега. Только не надо в качестве аргумента приводить убогий перевод Буча.

Ну вообще, я Буча и имел ввиду. А по поводу переводов, то тут не все гладко (lingvo):

cohesion — информ. сцепление. связность

А вообще да, я был неправ.

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

А>А вот для каких жизненных ситуаций может быть использован Singleton ?

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

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

M>>Я не утверждаю что такая ситуация присутствует всегда , вы сами привели яркие примеры не вписывающиеся в эту картину.
WH>Я тебе могу расказать как можно задедлочится на пуле... но ты почемуто считаешь что это невозможно

Мне расскажи.

Здравствуйте, Нахлобуч, Вы писали:

WH>>Я тебе могу расказать как можно задедлочится на пуле... но ты почемуто считаешь что это невозможно
Н>Мне расскажи.
1)Клиент спрашивает машину А. Машина А спрашивает машину Б. Машина Б спрашивает машину А. Если на машине А один пул потоков и клиенты много спрашивают то будет дедлок.
2)Есть две машины. Запросы от клиентов обрабатываются обе машины. Обычно справляются сами но иногда приходится спрашивать соседа. Если на каждой машине один пул то при большом колличестве запросов будет дедлок.
...
Обе описанные проблемы решаются отдельным пулом для внутренних запросов.

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

Это не считая баналностей типа: Задача которая выполняется в пуле хочет создать несколько асинхронных подзадач и дождаться от них ответа (например спросить несколько соседних серверов).
Очевидно если задачи и поздадачи засунуть в один пул то рано или поздно будет дедлок.

http://codelab.ru/pattern/singleton/

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

D>Избавление от singleton'а, конечно, не относится к классу Неразрешимых проблем. Однако, это может стать трудноразрешимой проблемой. По коду может быть разбросаны сотни ThreadPool.getInstance(), которые придется поменять.

Отрефакторить единообразный вызов "ThreadPool.getInstance()" даже в сотнях отдельных мест способен даже простейший текстовый редактор, умеющий делать замену по всем файлам заданного множества. Задача расширения одного синглтона до "массива синглтонов" вообще подозрительно усложнена: если в getInstance() добавить параметр — индекс или id синглтона в пуле — это проблема? Старые вызовы можно переписать как getInstance(0) — или же вынести 0 в параметр по умолчанию.

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

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

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

Тут я вообще не понял: а как тогда "юниттестировать" код, в котором активно используется любой другой объект? Ну вот даже упомянутый CString — он, конечно, не синглтон, но ведь везде используется — как такой код тестировать предполагается?

Имхо, вы ищете кошку там, где ее нет.

V>Вообще-то я просил привести пример, когда синглтон имеет _преимущества_ перед другими решениями (например, перед IoC). В примере с пулом потоков я никаких преимуществ кроме возможного в будущем гемороя не увидел.

В случае контекста — кто-то должен все время задавать этот самый контекст, каждый раз создавая его инстанс. В случае, если инстанс задается не каждый раз, а статичен — это фактически синглтон.

WH>Обе описанные проблемы решаются отдельным пулом для внутренних запросов.

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

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

_>А в чем сложность создать у класса-синглтона Pool 2 метода для получения этих 2-х разных пулов? Вопрос ведь в том, нужен ли нам экземпляр класса Pool или нет. В данном случае, вроде бы, не нужен.
То что конфигурация пулов и обработчиков задается конфигом.

_>>А в чем сложность создать у класса-синглтона Pool 2 метода для получения этих 2-х разных пулов? Вопрос ведь в том, нужен ли нам экземпляр класса Pool или нет. В данном случае, вроде бы, не нужен.
WH>То что конфигурация пулов и обработчиков задается конфигом.

Ну, скажем, у нас в проекте есть класс ConfigReader (кстати, синглтон ), который читает из .config файла. В случае, если файл меняется (отслеживается по ModifyDate) — на лету читает заново. Класс Pool может в ОБОИХ методах своих смотреть что там в .config через ConfigReader.

Или имеется в виду, что число пулов недетерменировано? Ну так вроде бы до этого вы говорили только про 2 пула?

Ну допустим даже, что их число недетерменированно. Условно говоря, в конфиге имеется набор соответствий "Тип пула (внутренний, внешний, ...) — Размер пула". Пусть тогда тот класс, который вызывает метод получения соединения (или чего там в пуле) через Pool передает этот тип пула. Если боитесь, что придется много кода переписывать — перегрузите метод, пусть по умолчанию это будет всегда внешний тип пула.

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

_>Или имеется в виду, что число пулов недетерменировано?
Детерминированно но зависит от задачи.

_>Ну так вроде бы до этого вы говорили только про 2 пула?
Гдето 2 гдето 1 гдето 10...

_>Ну допустим даже, что их число недетерменированно. Условно говоря, в конфиге имеется набор соответствий "Тип пула (внутренний, внешний, ...) — Размер пула". Пусть тогда тот класс, который вызывает метод получения соединения (или чего там в пуле) через Pool передает этот тип пула. Если боитесь, что придется много кода переписывать — перегрузите метод, пусть по умолчанию это будет всегда внешний тип пула.
Мне ничего не придется переписывать ибо нет синглетона нет проблемы.

У меня есть простой exe'ник который умеет читать конфиг и подгружать dll'ки.
Далие согласно конфигу этот exe'ник создает компоненты при помощи фабрик которые экспортируют dll'ки.
Соответственно есть компонент реализующий пул потоков.
Есть компонент принимающий подключение и по заголовку определяющий в каком пуле и каким обработчиком обработать запрос. Соответствие задается в конфиге.
Есть несколько компонентов реализующих разную обработку запросов.
И ессно есть еще куча всяких компонентов которые к разговору отношения не имеют.

Таким образом я создаю простые кирпичики которые потом собираются в сложную систему просто правкой конфигов.

WH>У меня есть простой exe'ник который умеет читать конфиг и подгружать dll'ки.
WH>Далие согласно конфигу этот exe'ник создает компоненты при помощи фабрик которые экспортируют dll'ки.
WH>Соответственно есть компонент реализующий пул потоков.
WH>Есть компонент принимающий подключение и по заголовку определяющий в каком пуле и каким обработчиком обработать запрос. Соответствие задается в конфиге.
WH>Есть несколько компонентов реализующих разную обработку запросов.
WH>И ессно есть еще куча всяких компонентов которые к разговору отношения не имеют.

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

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

_>Отличный вариант, просто таки Spring в нескольких предложениях
Дык! Если понимаешь что к чему то и описать можно в несколько предложений.

_>Теперь допустим нам нужно получить из нашего пула соединение. Инстансы каких классов при получении его будут созданы?
Ничего не понял.
Чего, зачем и откуда получить?

_>>Теперь допустим нам нужно получить из нашего пула соединение. Инстансы каких классов при получении его будут созданы?
WH>Ничего не понял.
WH>Чего, зачем и откуда получить?

соединение из ConnectionPool'а

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

_>>>Теперь допустим нам нужно получить из нашего пула соединение. Инстансы каких классов при получении его будут созданы?
WH>>Ничего не понял.
WH>>Чего, зачем и откуда получить?

_>соединение из ConnectionPool'а

Запрашиваем соеденение у ConnectionPool'а.
В чем проблема то?

_>>>>Теперь допустим нам нужно получить из нашего пула соединение. Инстансы каких классов при получении его будут созданы?
WH>>>Ничего не понял.
WH>>>Чего, зачем и откуда получить?

_>>соединение из ConnectionPool'а

WH>Запрашиваем соеденение у ConnectionPool'а.
WH>В чем проблема то?

Да нет проблем, инстансы каких классов будут созданы. Нужен ли нам инстанс класса ConnectionPool?

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

_>Да нет проблем, инстансы каких классов будут созданы. Нужен ли нам инстанс класса ConnectionPool?
Все что прописано в конфиге давно создано.
Компоненты получают при создании контекст из которого можно получить другой компонент.
Далие просто запрашиваем (и возможно гдето запоминаем) ConnectionPool и у него запрашиваем Connection.

_>>Да нет проблем, инстансы каких классов будут созданы. Нужен ли нам инстанс класса ConnectionPool?
WH>Все что прописано в конфиге давно создано.

И хранится в классе-синглтоне соответственно.

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

_>И хранится в классе-синглтоне соответственно.
Нет никакого синглетона.

_>>И хранится в классе-синглтоне соответственно.
WH>Нет никакого синглетона.

Тогда создаются лишние инстансы классов. Вот и все.

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

_>Тогда создаются лишние инстансы классов. Вот и все.
Не создаются.

_>>Тогда создаются лишние инстансы классов. Вот и все.
WH>Не создаются.

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

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

_>>>Тогда создаются лишние инстансы классов. Вот и все.
WH>>Не создаются.

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

Так значит нужно различать языки C++ и С# со сборкой мусора? Именно во втором случае Singleton — эффективен?