Re[14]: потокобезопасный Singleton
От: savaDAN  
Дата: 10.08.05 11:55
Оценка:
AVK>Пусть нам понадобилось запустить код BizEntity в другой системе с совершенно иной реализацией логгера. В первом варианте нам нужно будет перетаскивать исходники и править все вызовы логгера. Во-втором случае достаточно реализовать ILogger, при том даже перекомпилировать BizEntity не понадобится.
Т.е. вы предлагаете вместо синглтона использовать фабрику? Несомненно более гибкое решение (собно фабрику для этого и придумывали).
В другом вопрос: а как это влияет на связность? Теперь всем приложениям придется реализовывать ILogger

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

AVK>Едем дальше — вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно. И опять та же история. В первом варианте требуется перетряхивать логгер, менять семантику метода Log, либо вместо свойства Instance делать метод, соотвественно править код BizEntity и т.п. Во-втором варианте достаточно в нужном месте в контекст подсунуть нужный экземпляр. Опять же, при этом даже не требуется перекомпиляция BizEntity.

По мне так overhead небольшой — что менять Instance, что менять фабрику т.к. в любом случае придется перелопатить тонну кода клиентского

AVK>Третий вариант — нам нужно обеспечить подключение логгеров, написанных пользователем, путем указания имени класса в файле конфигурации. И опять та же история — перетряхать логгер, вводить механику выбора нужного экземпляра логгера.

ничем не отличается от предыдущего примера.

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

Но это не значит что всегда вместо синглтонов стоит делать фабрики. в том числе и для логгеров.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[27]: Потокобезопасный Singleton
От: mogadanez Чехия  
Дата: 10.08.05 11:56
Оценка: :))
Здравствуйте, Merle, Вы писали:

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


M>>....цитата из книги Банды Четырех

M>Да байта ради.. Они конечно дядьки хорошие, но совсем уж так уж тоже не стоит...
M>Суть-то как раз в том, что он действительно позволяет контролировать количество экземпляров, а не только ограничиваться одним. Один из банды, Влиссидес кажется, тракторвал этот паттерн именно так и даже приводил пример реального использования в этом качестве. И Википедия так же утверждает, что экземпляров может быть и несколько...

Да мегабайтом глянусь, согласен полностью, просто единственно что под рукой было откуда цитатку можно подрезать, они в спорах более убедительно звучат.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[18]: потокобезопасный Singleton
От: Аноним  
Дата: 10.08.05 12:18
Оценка:
А>>Тут дело не в спецификации Надо тебе несколько логгеров — пиши несколько; надо подменить один другим — подменяй.

AVK>Так вот в этом собака и порылась. Если тебе сначало не надо, а потом надо, то синглтон существенно усложняет модификацию кода.


Чем интересно? То есть твой пример с этим замечательным сервисом на основе интерфейса решает все? То же самое решит фабрика.

А>> Синглтон тут лишь средство избежать ненужного создания класса.

AVK>Какого?

Ненужного Каждый раз инстанс объекта не создается.

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

AVK>И? Вывод из этого какой?

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

вывод очевиден — твой довод не верен, не надо ничего перетряхать.
Re[15]: потокобезопасный Singleton
От: Аноним  
Дата: 10.08.05 12:20
Оценка:
DAN>В другом вопрос: а как это влияет на связность? Теперь всем приложениям придется реализовывать ILogger

А до этого видимо нет? Посмотри на то что предложил AndrewVK, то же самое

DAN>По мне так overhead небольшой — что менять Instance, что менять фабрику т.к. в любом случае придется перелопатить тонну кода клиентского


Вот именно

DAN>Но это не значит что всегда вместо синглтонов стоит делать фабрики. в том числе и для логгеров.


Точно Именно это главное.
Re[15]: потокобезопасный Singleton
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.08.05 13:13
Оценка:
Здравствуйте, savaDAN, Вы писали:

DAN>В другом вопрос: а как это влияет на связность? Теперь всем приложениям придется реализовывать ILogger


Зачем?

DAN>С точки зрения логгера — ну будет у вас в одном приложении Logger.Instance возвращать один логгер, а в другом — другой.


Logger.Instance это реализация. Отделить интерфейс нам не удастся. Это значит, что максимум, что мы сможем обеспечить, это перенос исходников и точное совпадение полного имени логгера во всех приложениях.

AVK>>Едем дальше — вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно. И опять та же история. В первом варианте требуется перетряхивать логгер, менять семантику метода Log, либо вместо свойства Instance делать метод, соотвественно править код BizEntity и т.п. Во-втором варианте достаточно в нужном месте в контекст подсунуть нужный экземпляр. Опять же, при этом даже не требуется перекомпиляция BizEntity.

DAN>По мне так overhead небольшой — что менять Instance, что менять фабрику т.к. в любом случае придется перелопатить тонну кода клиентского

Зачем? Процесс создания экземпляра во втором варианте от прикладного кода скрыт. Его, при смене политики управления экземплярами, даже перекомпилировать не придется. А вот с синглтоном такое так просто уже не провернешь.

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

DAN>Но это не значит что всегда вместо синглтонов стоит делать фабрики. в том числе и для логгеров.

А я этого и не говорил.
... << RSDN@Home 1.2.0 alpha rev. 599>>
AVK Blog
Re[19]: потокобезопасный Singleton
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.08.05 13:13
Оценка:
Здравствуйте, <Аноним>, Вы писали:

AVK>>Так вот в этом собака и порылась. Если тебе сначало не надо, а потом надо, то синглтон существенно усложняет модификацию кода.


А>Чем интересно? То есть твой пример с этим замечательным сервисом на основе интерфейса решает все?


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

А> То же самое решит фабрика.


А IServiceProvider и есть фабрика.

А>>> Синглтон тут лишь средство избежать ненужного создания класса.

AVK>>Какого?

А>Ненужного Каждый раз инстанс объекта не создается.


В этом топике определение синглтона уже приводили. Повторю:

Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа

Ничего про каждый раз тут не сказано. Алгоритм создания этим паттерном не специфицируется.

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

AVK>>И? Вывод из этого какой?

А>"Третий вариант — нам нужно обеспечить подключение логгеров, написанных пользователем, путем указания имени класса в файле конфигурации. И опять та же история — перетряхать логгер, вводить механику выбора нужного экземпляра логгера."


А>вывод очевиден — твой довод не верен, не надо ничего перетряхать.


Мой вывод касался исключительно связности, вызываемой синглтоном. Ничего про log4net я не писал, тем более что для получения экземпляра логгера он использует фабрику LogManager.
... << RSDN@Home 1.2.0 alpha rev. 599>>
AVK Blog
Re[20]: потокобезопасный Singleton
От: Аноним  
Дата: 10.08.05 13:23
Оценка:
AVK>А IServiceProvider и есть фабрика.
Я про это и говорил — "та же фабрика, но от микрософт"

AVK>В этом топике определение синглтона уже приводили. Повторю:

AVK>

Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа

AVK>Ничего про каждый раз тут не сказано. Алгоритм создания этим паттерном не специфицируется.

Создается за время работы приложения только один раз = не создается во время работы каждый раз когда тебе объект нужен.

AVK>Мой вывод касался исключительно связности, вызываемой синглтоном. Ничего про log4net я не писал, тем более что для получения экземпляра логгера он использует фабрику LogManager.


Я просто про то что не надо ничего перетряхать

Вообще, предлагаю и закрыть тему
Re[16]: потокобезопасный Singleton
От: Аноним  
Дата: 10.08.05 13:25
Оценка:
AVK>Logger.Instance это реализация. Отделить интерфейс нам не удастся. Это значит, что максимум, что мы сможем обеспечить, это перенос исходников и точное совпадение полного имени логгера во всех приложениях.

Logger : ILog
То есть такого быть не может? Может и еще как легко может.

AVK>Зачем? Процесс создания экземпляра во втором варианте от прикладного кода скрыт. Его, при смене политики управления экземплярами, даже перекомпилировать не придется. А вот с синглтоном такое так просто уже не провернешь.


ну тут фактори поможет. Но все равно иногда синглтоны нужны as is. Нельзя же в конце концов над всеми классами фактори строить. Можно кстати синглтон как обертку над каким-нибудь классом сделать.
Re[21]: потокобезопасный Singleton
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.08.05 13:34
Оценка:
Здравствуйте, <Аноним>, Вы писали:

AVK>>А IServiceProvider и есть фабрика.

А>Я про это и говорил — "та же фабрика, но от микрософт"

И?

AVK>>Мой вывод касался исключительно связности, вызываемой синглтоном. Ничего про log4net я не писал, тем более что для получения экземпляра логгера он использует фабрику LogManager.


А>Я просто про то что не надо ничего перетряхать


Если не использовать синглтон, то не надо.
... << RSDN@Home 1.2.0 alpha rev. 599>>
AVK Blog
Re[16]: потокобезопасный Singleton
От: savaDAN  
Дата: 10.08.05 13:39
Оценка:
DAN>>В другом вопрос: а как это влияет на связность? Теперь всем приложениям придется реализовывать ILogger
AVK>Зачем?

Пусть нам понадобилось запустить код BizEntity в другой системе с совершенно иной реализацией логгера. В первом варианте нам нужно будет перетаскивать исходники и править все вызовы логгера

.. А в вашем варианте приложению в которое вставляют BizEntity придется реализовывать ILogger интерфейс.
Т.е. от того что синглтон стал фабрикой _связность_ (как количество знаний данного класса о других классах) не изменилась.. она даже увеличилась: мало того что надо знать об ILogger, так еще и о Context-ах.

С другой стороны, кто мешает в разных системах делать в таком случае свои реализации Logger.Instance которые будут возвращать разные реализации (в разных системах) ILogger? Синглтоном он от этого имхо быть не перестанет.


DAN>>С точки зрения логгера — ну будет у вас в одном приложении Logger.Instance возвращать один логгер, а в другом — другой.

AVK>Logger.Instance это реализация. Отделить интерфейс нам не удастся. Это значит, что максимум, что мы сможем обеспечить, это перенос исходников и точное совпадение полного имени логгера во всех приложениях.
Упихивание разных логгеров в ILogger это по большому счету не одно и тоже?


AVK>>>Едем дальше — вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно. И опять та же история. В первом варианте требуется перетряхивать логгер, менять семантику метода Log, либо вместо свойства Instance делать метод, соотвественно править код BizEntity и т.п. Во-втором варианте достаточно в нужном месте в контекст подсунуть нужный экземпляр. Опять же, при этом даже не требуется перекомпиляция BizEntity.

DAN>>По мне так overhead небольшой — что менять Instance, что менять фабрику т.к. в любом случае придется перелопатить тонну кода клиентского
AVK>Зачем? Процесс создания экземпляра во втором варианте от прикладного кода скрыт. Его, при смене политики управления экземплярами, даже перекомпилировать не придется. А вот с синглтоном такое так просто уже не провернешь.
Тогда видимо я вас не так понял.

вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно.


        // do some work
        Context.GetService<ILogger>().Log("Work done");

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

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

DAN>>Но это не значит что всегда вместо синглтонов стоит делать фабрики. в том числе и для логгеров.

AVK>А я этого и не говорил.

Прошу прощения!
Беру свои слова обратно.
Я собственно тоже только хотел сказать что использование фабрики вместо синглтона связность не уменьшает
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[17]: потокобезопасный Singleton
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.08.05 13:48
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Logger : ILog

А>То есть такого быть не может? Может и еще как легко может.

Может. Но в ILog не может быть статического свойства Instance. А проблема именно в жесткой привязке прикладного кода к этому свойству.

AVK>>Зачем? Процесс создания экземпляра во втором варианте от прикладного кода скрыт. Его, при смене политики управления экземплярами, даже перекомпилировать не придется. А вот с синглтоном такое так просто уже не провернешь.


А>ну тут фактори поможет.


Поможет. Есть и другие, более сложные паттерны.

А> Но все равно иногда синглтоны нужны as is.


Не то чтобы нужны, но иногда их использовать проще. Я же не говорил, что их вобще использовать не стоит. Я говорил о том что они увеличивают связность программы, т.е. за все надо платить, в том числе и за удобство доступа. И, в случае библиотек, частенько такая плата оказывается неприемлемой.
... << RSDN@Home 1.2.0 alpha rev. 599>>
AVK Blog
Re[17]: потокобезопасный Singleton
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.08.05 14:09
Оценка: +1
Здравствуйте, savaDAN, Вы писали:

AVK>>Зачем?

DAN>

DAN>Пусть нам понадобилось запустить код BizEntity в другой системе с совершенно иной реализацией логгера. В первом варианте нам нужно будет перетаскивать исходники и править все вызовы логгера

DAN>.. А в вашем варианте приложению в которое вставляют BizEntity придется реализовывать ILogger интерфейс.

Или воспользоваться одной из готовых реализаций. Но даже если придется, то в системном коде 1 раз. Трогать прикладной код при этом не нужно. Надеюсь доказывать, что неизменность прикладного кода намного важнее не надо?

DAN>Т.е. от того что синглтон стал фабрикой _связность_ (как количество знаний данного класса о других классах) не изменилась.. она даже увеличилась: мало того что надо знать об ILogger, так еще и о Context-ах.


Изменилась. Потому что во втором варианте прикладной код знает только о публичном интерфейсе и ничего о реализации. А вот в первом он знает и о реализации.

DAN>С другой стороны, кто мешает в разных системах делать в таком случае свои реализации Logger.Instance которые будут возвращать разные реализации (в разных системах) ILogger? Синглтоном он от этого имхо быть не перестанет.


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

AVK>>Logger.Instance это реализация. Отделить интерфейс нам не удастся. Это значит, что максимум, что мы сможем обеспечить, это перенос исходников и точное совпадение полного имени логгера во всех приложениях.

DAN>Упихивание разных логгеров в ILogger это по большому счету не одно и тоже?

Нет.

AVK>>Зачем? Процесс создания экземпляра во втором варианте от прикладного кода скрыт. Его, при смене политики управления экземплярами, даже перекомпилировать не придется. А вот с синглтоном такое так просто уже не провернешь.

DAN>Тогда видимо я вас не так понял.
DAN>

DAN>вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно.


DAN>
DAN>        // do some work
DAN>        Context.GetService<ILogger>().Log("Work done");
DAN>

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

Очень просто. AddService вызывает системный код где то за кадром. И что и когда он туда добавит прикладной код не знает. Он может добавить один раз при старте, может один раз при первом запросе, может где нибудь вниз по стеку перекрыть реализацию другой.

DAN>Вот поэтому я и говорил — клиентский код придется менять.


Зачем? Вот тот же пример, только более подробный:
// System code
public class Server
{
    public void DoSomeWork()
    {
        ServerContext ctx = new ServerContext();
        ctx.AddService<ILogger>(new FileLogger(...));
        GetEntity(ctx).Foo();
    }
}

// Client code
public class BizEntity
{
    public void Foo()
    {
        // do some work
        Context.GetService<ILogger>().Log("Work done");
    }
}


Что в прикладном коде придется менять при изменении политики управления экземплярами логгера?

DAN>>>Но это не значит что всегда вместо синглтонов стоит делать фабрики. в том числе и для логгеров.

AVK>>А я этого и не говорил.
DAN>Прошу прощения!
DAN>Беру свои слова обратно.
DAN>Я собственно тоже только хотел сказать что использование фабрики вместо синглтона связность не уменьшает

Таки уменьшает.
... << RSDN@Home 1.2.0 alpha rev. 599>>
AVK Blog
Re[27]: Потокобезопасный Singleton
От: mogadanez Чехия  
Дата: 11.08.05 09:59
Оценка:
Здравствуйте, Merle, Вы писали:


M>Суть-то как раз в том, что он действительно позволяет контролировать количество экземпляров, а не только ограничиваться одним. Один из банды, Влиссидес кажется, тракторвал этот паттерн именно так и даже приводил пример реального использования в этом качестве. И Википедия так же утверждает, что экземпляров может быть и несколько...


кстати открыл щас книженцию Влиссидеса ( Доп штрихи к паттернам или как то так... ) там глава есть, "избавляемся от Синглтона", так там такое же определение.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[28]: Потокобезопасный Singleton
От: Merle Австрия http://rsdn.ru
Дата: 11.08.05 10:42
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>кстати открыл щас книженцию Влиссидеса ( Доп штрихи к паттернам или как то так... ) там глава есть, "избавляемся от Синглтона", так там такое же определение.

Ткое же — это какое? Там глава должна быть про безопасность и там в системе как раз используется синглтон, который именно контролирует количество объектов, а не ограничивает одним...
... << RSDN@Home 1.1.4 beta 7 rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[13]: Потокобезопасный Singleton
От: Аноним  
Дата: 09.08.05 18:47
Оценка:
To AndrewVK:

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

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

С уважением, Олег Аксенов.
MDNA


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re[14]: Потокобезопасный Singleton
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.08.05 13:05
Оценка: 3 (1)
Здравствуйте, OlegAxenow, Вы писали:

OA>Можно подтверждающий пример или ссылку на документацию?


Можно.
using System;

class Logger
{
    public static readonly Logger Instance = new Logger();

    private Logger()
    {
        Console.WriteLine("Logger initialized");
    }

    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

class Logger2
{
    private class InstanceHolder
    {
        public static readonly Logger2 Instance = new Logger2();
    }

    public static Logger2 Instance
    {
        get { return InstanceHolder.Instance; }
    }

    private Logger2()
    {
        Console.WriteLine("Logger2 initialized");
    }

    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

class Program
{
    static void Main()
    {
        try
        {
            Console.WriteLine("Do some work");
        }
        catch (Exception ex)
        {
            Logger.Instance.Log(ex.Message);
            Logger2.Instance.Log(ex.Message);
        }
    }
}
... << RSDN@Home 1.2.0 alpha rev. 599>>
AVK Blog
Re[29]: Потокобезопасный Singleton
От: mogadanez Чехия  
Дата: 11.08.05 13:17
Оценка:
Здравствуйте, Merle, Вы писали:

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


M>>кстати открыл щас книженцию Влиссидеса ( Доп штрихи к паттернам или как то так... ) там глава есть, "избавляемся от Синглтона", так там такое же определение.

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

Наверное другая книжка...

В общем не знаю как там у них написано, но имя у паттерна должно быть говорящим... Singleton — мне говорит что он может быть один. контролирующий число объектов я бы уже назвыал другим паттерном, хотя на вкус и цвет....
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[14]: Потокобезопасный Singleton
От: Аноним  
Дата: 11.08.05 14:05
Оценка:
>OA>Можно подтверждающий пример или ссылку на документацию?
>Можно.

А почему коструктором-то не воспользоваться?
То есть вместо
public static readonly Logger Instance = new Logger();

Написать:
public static readonly Logger Instance;
static Logger()
{
 Instance = new Logger();
}

Или с Holder'ом интереснее?

С уважением, Олег Аксенов.
MDNA


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re[30]: Потокобезопасный Singleton
От: Merle Австрия http://rsdn.ru
Дата: 11.08.05 20:03
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>Наверное другая книжка...

может быть...
Кстати, вот, цитата из собственно GoF, раздел "Результаты":

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


M>Singleton — мне говорит что он может быть один. контролирующий число объектов я бы уже назвыал другим паттерном, хотя на вкус и цвет....

Да нет, паттерн-то абсолютно тот же, просто условия создания экземпляра чуть сложнее, не думаю, что имеет смысл выделять это в отдельный паттерн.
... << RSDN@Home 1.1.4 beta 6a rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[14]: Потокобезопасный Singleton
От: Аноним  
Дата: 12.08.05 06:47
Оценка:
2 OlegAxenow:

А разве
public static readonly Logger Instance = new Logger();

и
public static readonly Logger Instance;
static Logger()
{
 Instance = new Logger();
}

не одно и тоже?
И там и там экземпляр создается статическим конструктором.


В примере AndrewVK, синглтон создается только при непосредственном обращении к статическому свойству Instance. В то время как в Вашем примере, создание синглтона произойдет при любом обращении к классу Logger.
________________________________
Best regards, Oleg Ufaev
Rostov .Net User Group
Конкурсная заявка


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.