Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Tom, Вы писали:
Tom>>Суть в том что при использовании паттерна одиночка нет никакой разница вызывать статический метод или мембер. Tom>>т.е Tom>>Foo.Instance.Bar() = Foo.Bar()
L>Неужто? Заче тогда вообще городить Singleton, если нет никакой разницы между Singleton-ом и просто набором статических методов?
Затем, что бы был инстанс, что даём много возможностей, как то серилизацию итп...
Кстате если не согласен — может аргументируешь?
Здравствуйте, Lloyd, Вы писали:
L>Маладца. Переименовал внутренний класс и дописал пару методов. Ты по ветке-то поднимись и сравни то что ты написал и написал я.
Да, та же фигня. Но я говорил о дабл-локинге, как о совершенно ненужном в C# механизме.
L>С++ — то к чему здесь приплел?
К извращениям. Например, в MС++ можно бросить исключение, не производное от Exception.
L>Не спеши с выводами. Раз уж ты взялся рассуждать о дизайне, скажи пожалуйста, какую сущность выражает твой внутренний класс Core?
Этот класс выражает не сущьность, он — вынужденная мера, вызванная сваливанием в одну кучу (почему-то именуемую Singleton) разношерстных методов (кому нужны стат. переменные и кому они не нужны).
Раз уж ты спрашиваешь о дизане, расскажи, что делают в Singleton-е методы, не использующие статические переменные.
Здравствуйте, Tom, Вы писали:
Tom>Затем, что бы был инстанс, что даём много возможностей, как то серилизацию итп... Tom>Кстате если не согласен — может аргументируешь?
Понятно. По четным дням значит разница есть, а по нечетным — нет?
Здравствуйте, Andrbig, Вы писали:
L>>Маладца. Переименовал внутренний класс и дописал пару методов. Ты по ветке-то поднимись и сравни то что ты написал и написал я.
A>Да, та же фигня. Но я говорил о дабл-локинге, как о совершенно ненужном в C# механизме.
Не спеши. Вспоминаем бритву Оккама + тот факт, что ооп предполагает использование классов для 'обозначения' неких сущностей.
L>>С++ — то к чему здесь приплел?
A>К извращениям. Например, в MС++ можно бросить исключение, не производное от Exception.
Это тема отделного разговора. Ничего криминального лично я в этой возможности не вижу.
L>>Не спеши с выводами. Раз уж ты взялся рассуждать о дизайне, скажи пожалуйста, какую сущность выражает твой внутренний класс Core?
A>Этот класс выражает не сущьность, он — вынужденная мера, вызванная сваливанием в одну кучу (почему-то именуемую Singleton) разношерстных методов (кому нужны стат. переменные и кому они не нужны).
То есть у этого подхода есть таки недостатки по-крайней мере с точки зрения дизайна. Не так ли?
A>Раз уж ты спрашиваешь о дизане, расскажи, что делают в Singleton-е методы, не использующие статические переменные.
Представления не имею. Написал их кто-то вот они что-то и делаеют. Да на самом деле, как показал AndrewVK, некорректное поведение возможно и в отсутствии 'посторонних' методов.
L>Понятно. По четным дням значит разница есть, а по нечетным — нет?
Делать метод из мембера статическим при использовании патерна одиночка смысла нет. Иметь инстанс смысл есть.
Здравствуйте, Tom, Вы писали:
L>>Понятно. По четным дням значит разница есть, а по нечетным — нет? Tom>Делать метод из мембера статическим при использовании патерна одиночка смысла нет. Иметь инстанс смысл есть.
А как ты убедишь компилятор при обращении к полю Singleton.Instance чтобы он возвращал Singleton.SingletonInstanceHolder.SingletonInstance.
Извини, но я не знаю как такое сделать.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Tom, Вы писали:
L>>>Понятно. По четным дням значит разница есть, а по нечетным — нет? Tom>>Делать метод из мембера статическим при использовании патерна одиночка смысла нет. Иметь инстанс смысл есть.
L>А как ты убедишь компилятор при обращении к полю Singleton.Instance чтобы он возвращал Singleton.SingletonInstanceHolder.SingletonInstance. L>Извини, но я не знаю как такое сделать.
Я тоже ) Мне просто холдер не нужен
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Народная мудрось
всем все никому ничего(с).
Re[12]: потокобезопасный Singleton
От:
Аноним
Дата:
10.08.05 08:45
Оценка:
AVK>В принципе, если его вобще не использовать, может . А если серьезно, то примеры в студию.
Ну например тот же логгер-синглтон. Он никак не влияет на каплинг.
Здравствуйте, Lloyd, Вы писали:
L>Не спеши. Вспоминаем бритву Оккама + тот факт, что ооп предполагает использование классов для 'обозначения' неких сущностей.
И?
L>Это тема отделного разговора. Ничего криминального лично я в этой возможности не вижу.
Согласен, отдельного. Поймай на C# это исключение и я тоже не стану видеть ничего криминального.
A>>Этот класс выражает не сущьность, он — вынужденная мера, вызванная сваливанием в одну кучу (почему-то именуемую Singleton) разношерстных методов (кому нужны стат. переменные и кому они не нужны).
L>То есть у этого подхода есть таки недостатки по-крайней мере с точки зрения дизайна. Не так ли?
Которого этого? Недостаточки с т.зр. дизайна есть у сваливания в одну кучу разношерстных методов.
L>Представления не имею. Написал их кто-то вот они что-то и делаеют.
Если никто не имеет предстваления и все всё сваливают все в кучу, то вообще сложно говорить о дизайне, не находишь?
L>Да на самом деле, как показал AndrewVK, некорректное поведение возможно и в отсутствии 'посторонних' методов.
Согласен. Для этого внутренний класс. Но уж никак не дабл-локинг.
Здравствуйте, Andrbig, Вы писали:
A>Согласен, отдельного. Поймай на C# это исключение и я тоже не стану видеть ничего криминального.
Проще простого
catch {}
L>>То есть у этого подхода есть таки недостатки по-крайней мере с точки зрения дизайна. Не так ли?
A>Которого этого? Недостаточки с т.зр. дизайна есть у сваливания в одну кучу разношерстных методов.
Я всегда считал, что в ооп классы служат для отображения сущностей предметной области, а не для того, чтобы избежать столь нелюбимого тобой дабл-локинга. Извини, если я ошибался.
L>>Да на самом деле, как показал AndrewVK, некорректное поведение возможно и в отсутствии 'посторонних' методов. A>Согласен. Для этого внутренний класс. Но уж никак не дабл-локинг.
Внутренний класс — это привнесений лишней сущности в программу. А дядя Оккам нам крайне не советует делать этого без лишней на то необходимости.
Здравствуйте, Tom, Вы писали:
L>>Я правильно понял твою мысль, что ты хотел сказать, что приватный внутренний класс ты считаешь ненужным? Tom>Правильно
Тогда прокомментируй пожалуйста пример который привел AndrewVK. Ты считаешь нормальной ситуацию когда синглтон создается хотя реального обращения к нему не было?
И как ты отличишь, что именно ты поймал?
L>Я всегда считал, что в ооп классы служат для отображения сущностей предметной области, а не для того, чтобы избежать столь нелюбимого тобой дабл-локинга. Извини, если я ошибался.
Не извиню. Потому что неизвестно, ошибался ты или нет. Пока что мы вилами по воде пишем. Приведи конкретный пример сущности предметной области, посмотрим как она соотнесется с классами, а там уж и будем решать кто есть ху.
L>Внутренний класс — это привнесений лишней сущности в программу. А дядя Оккам нам крайне не советует делать этого без лишней на то необходимости.
Я не уверен, что дядя Оккам знал про особенности .NET.
Здравствуйте, <Аноним>, Вы писали:
AVK>>В принципе, если его вобще не использовать, может . А если серьезно, то примеры в студию.
А>Ну например тот же логгер-синглтон. Он никак не влияет на каплинг.
Очень даже влияет. Вот например:
// Singletonpublic class BizEntity
{
public void Foo()
{
// do some work
System1.Logger.Instance.Log("Work done");
}
}
// IServiceProviderpublic class BizEntity
{
public void Foo()
{
// do some work
Context.GetService<ILogger>().Log("Work done");
}
}
Пусть нам понадобилось запустить код BizEntity в другой системе с совершенно иной реализацией логгера. В первом варианте нам нужно будет перетаскивать исходники и править все вызовы логгера. Во-втором случае достаточно реализовать ILogger, при том даже перекомпилировать BizEntity не понадобится.
Едем дальше — вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно. И опять та же история. В первом варианте требуется перетряхивать логгер, менять семантику метода Log, либо вместо свойства Instance делать метод, соотвественно править код BizEntity и т.п. Во-втором варианте достаточно в нужном месте в контекст подсунуть нужный экземпляр. Опять же, при этом даже не требуется перекомпиляция BizEntity.
Третий вариант — нам нужно обеспечить подключение логгеров, написанных пользователем, путем указания имени класса в файле конфигурации. И опять та же история — перетряхать логгер, вводить механику выбора нужного экземпляра логгера.
Налицо значительно более высокая связность варианта с синглтоном, приводящая к тому что код с синглтонами хуже масштабируется.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Tom, Вы писали:
L>>>Я правильно понял твою мысль, что ты хотел сказать, что приватный внутренний класс ты считаешь ненужным? Tom>>Правильно
L>Тогда прокомментируй пожалуйста пример который привел AndrewVK. Ты считаешь нормальной ситуацию когда синглтон создается хотя реального обращения к нему не было?
Ну создаётся. Никакой проблеммы тут нет. Обычно синглтоны создаются при старте приложения, и живут до его смерти. Если требуется что то более умное то нужно применять другой паттерт, позволяющий гибко управлять временем жизни обьекта.
Здравствуйте, Andrbig, Вы писали:
A>И как ты отличишь, что именно ты поймал?
И на основе того, что в C#-е мы не можем этого сделать ты делаешь вывод о кривизне плюсов?
L>>Я всегда считал, что в ооп классы служат для отображения сущностей предметной области, а не для того, чтобы избежать столь нелюбимого тобой дабл-локинга. Извини, если я ошибался.
A>Не извиню. Потому что неизвестно, ошибался ты или нет. Пока что мы вилами по воде пишем. Приведи конкретный пример сущности предметной области, посмотрим как она соотнесется с классами, а там уж и будем решать кто есть ху.
Для чего тебе это? Ты хочеь обсудить должны ли объекты использоваться как объекты или их можно использовать в том числе и для различных трюков? Если да, то этот вопрос не для этого форума.
A>Я не уверен, что дядя Оккам знал про особенности .NET.
Здравствуйте, Andrbig, Вы писали:
L>>Да на самом деле, как показал AndrewVK, некорректное поведение возможно и в отсутствии 'посторонних' методов. A>Согласен. Для этого внутренний класс. Но уж никак не дабл-локинг.
Иногда логика проверки и создания экземпляра синглтона значительно хитрее, нежели проверка на null. Например синглтон это файл конфигурации и при каждом обращении надо проверять, не изменился ли файл, и, если изменился, перегружать его. В таком случае условие проверки нужно в любом случае писать вручную и статические конструкторы никаким боком не прокатывают. Вот в этом случае, если нам нужна потокобезопасность, double check locking будет вполне нормальным паттерном (если не забывать про volatile). Даже на C#.
Здравствуйте, Tom, Вы писали:
Tom>Ну создаётся. Никакой проблеммы тут нет. Обычно синглтоны создаются при старте приложения, и живут до его смерти. Если требуется что то более умное то нужно применять другой паттерт, позволяющий гибко управлять временем жизни обьекта.
Ну а я считаю, что то, что существует должно существовать лишь постолько поскольку имеется в нем необходимость. Если необходимости в существовании экземпляра синглетона в данный момент нет, то он и не должен создаваться.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Andrbig, Вы писали:
L>>>Да на самом деле, как показал AndrewVK, некорректное поведение возможно и в отсутствии 'посторонних' методов. A>>Согласен. Для этого внутренний класс. Но уж никак не дабл-локинг.
AVK>Иногда логика проверки и создания экземпляра синглтона значительно хитрее, нежели проверка на null. Например синглтон это файл конфигурации и при каждом обращении надо проверять, не изменился ли файл, и, если изменился, перегружать его. В таком случае условие проверки нужно в любом случае писать вручную и статические конструкторы никаким боком не прокатывают. Вот в этом случае, если нам нужна потокобезопасность, double check locking будет вполне нормальным паттерном (если не забывать про volatile). Даже на C#.
Согласен. Но это лишь иногда. Для вполне определенных частных случаев.
