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

IT>Здравствуйте, Константин Л., Вы писали:

КЛ>>А это, пардон, откуда?

IT>Попытайся мыслить абстрактно.

попытался, но как ты сам сказал, "а впрыскивать кто будет?"

КЛ>>Да и разницы особой не вижу

IT>Здрасьте. Рома больше всего протестует по причине наличия у всей цепочки вызываемых методов дополнительного параметра. Скажу тебе по секрету. Такие параметры элементарно убираются и никаких проблем не вызывают.

Спасибо, что открыл тайну по секрету

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

Ну да ладно, полезность dep. inj. никто не оспаривает. Никто особо и не оспаривает наличие проблем у синглтона. Но вот устраивать охоту на ведьм и делать из IoC пришествие Христа тоже не рулез.

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

WH>Она подменилась после того как наколбасили 10 метров кода... Или ты хочешь сказать что у тебя никогда требования не меняются?
WH>В случае с Dependency injection проблем не возникает, а вот как такое провернуть на синглетонах...

Если я правильно понял твою задачу, то достаточно в качестве синглтона возвращать нечто реализующее chain of responsibility. Будет помесь двух паттернов. Добавятся методы внедрения и удаления звеньев, но существующий код переписывать не придётся.

WH>Если она вызывает мой код то все приличные библиотеки позволяют передать в Callback контекст вызова, а теми которые не позволяют это пользоваться в любом случае себе дороже.

Да тут понимаешь, в теории-то всё хорошо. А на практике бывает, что формально контекст вызова указать можно, но практически это какой-нибудь LPVOID. И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере

Кроме того, был опущен вопрос времени жизни. В случае с сервисами я объязан их все создать заранее, просто чтобы зарегистрировать у провайдера, в случае с синглтонами ненужной инициализации нет. Конечно, можно всё обернуть в Lazy Initialization, но это уже больше похоже на костыли...

Здравствуйте, Константин Л., Вы писали:

КЛ>Убираются, запихиваясь во всевозможные контексты и т.п.

Только не в контексты, а в конструкторы или инициализаторы объектов.

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

A>Если я правильно понял твою задачу, то достаточно в качестве синглтона возвращать нечто реализующее chain of responsibility. Будет помесь двух паттернов. Добавятся методы внедрения и удаления звеньев, но существующий код переписывать не придётся.
Псевдокод можно? А то словами у тебя както не очень получилось объяснить.

A>Да тут понимаешь, в теории-то всё хорошо. А на практике бывает, что формально контекст вызова указать можно, но практически это какой-нибудь LPVOID.
Больше и не нужно.

A>И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере
Ни разу со временем жизни проблем не возникало.

A>Кроме того, был опущен вопрос времени жизни. В случае с сервисами я объязан их все создать заранее, просто чтобы зарегистрировать у провайдера, в случае с синглтонами ненужной инициализации нет. Конечно, можно всё обернуть в Lazy Initialization, но это уже больше похоже на костыли...
Я вот не помню ни одного случая когда отложенная инициализация имела смысл.
У меня постоянно получается что момент создания/разрушения сервисов строго определен.
Что я делаю не так?

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

[]

A>Да тут понимаешь, в теории-то всё хорошо. А на практике бывает, что формально контекст вызова указать можно, но практически это какой-нибудь LPVOID. И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере

ну это уже проблема с++, а не dep. inj.

[]

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

IT>Здравствуйте, Константин Л., Вы писали:

КЛ>>Убираются, запихиваясь во всевозможные контексты и т.п.

IT>Только не в контексты, а в конструкторы или инициализаторы объектов.

А это можно было и не говорить.

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

Здравствуйте, Константин Л., Вы писали:

IT>>Только не в контексты, а в конструкторы или инициализаторы объектов.
КЛ>А это можно было и не говорить.
КЛ>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.

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

C>Здравствуйте, Константин Л., Вы писали:

IT>>>Только не в контексты, а в конструкторы или инициализаторы объектов.
КЛ>>А это можно было и не говорить.
КЛ>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
C>То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.

ну что за манера все доводить до абсурда?

Здравствуйте, Константин Л., Вы писали:

IT>>Только не в контексты, а в конструкторы или инициализаторы объектов.

КЛ>А это можно было и не говорить.

Это нужно было сказать сразу. Иначе Рома опять истолкует всё по-своему.

КЛ>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.

А в чём проблема?

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

[]

КЛ>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.

IT>А в чём проблема?

а видимо в том, что есть случаи когда это просто не нужно

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

C>Здравствуйте, Константин Л., Вы писали:

КЛ>>Ты серьезно? Неужели у нас _вообще_ не бывает глобально одиноких сущностей, в приципе?
C>А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?
КЛ>>Зависимость? ну так строй все на интерфейсах. Совсем уйти от зависимости тебе и IServiceProvider не поможет.
C>Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.

дык, библиотеки и прикладной код это две разные вещи.

Здравствуйте, Константин Л., Вы писали:

C>>Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.
КЛ>дык, библиотеки и прикладной код это две разные вещи.
И что? От библиотеки все что требуется — уметь передавать контекст. Бывают исключения, но уж очень редко.

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

A>Боже... ты неисправим... Винигрета никакого нет, просто я с дуру не так расставил ударения,
Ну, то есть, это я виноват, что ты даже не читаешь, что цитируешь..

A> Вот вобщем самая правильная цитата, тут ты уже не отвертишься.
Да куда уж мне, только умоляю, пафос убери..

A> класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;
Ооох, Ромушка... =) Ну когда же ты хоть сам себя-то читать научишься? Здесь опять речь о порождающей иерархии.
Более того, паттерн не обязательно должен удовлетворять всем пунктам из этого раздела. Это раздел о том, когда паттерн надо применять, а не описанеи паттерна.

A>см цитату выше.
С цитатами у тебя как-то не очень получается.. Своя голова есть?

A>Где тут доступ к приватным полям?
Нда, и после этого меня упрекают в буквоедстве...

A>Если по простому, IoC придумали чтобы избежать циклических зависимостей, для разрешения которых приходится, обычно, порождать лишние модули


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

Здравствуйте, Константин Л., Вы писали:

КЛ>Ну как бы за создание экземпляра и его уникальность отвечает совсем другой класс

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

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

КЛ>Чувак и лажа появились не просто так, а в ответ на твою учительско-дневниковскую манеру высказывать своё мнение. Вот она и тут проявилась
Хм.. У людей с адекватной самооценкой мой стиль изложения почему-то не вызывает негативной реакции. И то, что ты повел себя как нашкодивший ученик, говорит совсем не в твою пользу..

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

WH>Псевдокод можно? А то словами у тебя както не очень получилось объяснить.

Можно.

БЫЛО

// типы
template <typename T>
class singleton
{
    public:
        static T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class logger
{
    friend singleton<logger>;

    private:
        logger();
    public:
        void log(const char * message) const;
}
// использование
singleton<logger>.get_instance().log("some text");

СТАЛО

// типы
template <typename T>
class singleton
{
    public:
        static T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class logging_part
{
    public:
        virtual void log(char * message, bool * is_canceled, bool * is_handled) = 0;
}

class text_logging_part : public logging_part
{
    public:
        virtual void log(char * message, bool * is_canceled, bool * is_handled);
}

class db_logging_part : public logging_part
{
    public:
        virtual void log(char * message, bool * is_canceled, bool * is_handled);
}

class logger
{
    public:
        void log(const char * message) const;    
        void add_part(logging_part * log, /* какие-то параметры указывающие приоритет вызова и т.п. */);
        void remove_part(logging_part * log);
}
// использование
text_logging_part tl;
db_logging_part dl;

singleton<logger>.get_instance().add_part(tl);

singleton<logger>.get_instance().add_part(dl);

// Вот тут ничего не поменялось. Если нужна ещё и бинарная совместимость, то делаем интерфейсы.
singleton<logger>.get_instance().log("some text");

A>>И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере
WH>Ни разу со временем жизни проблем не возникало.

Проблема очевидная. Пишешь managed обёртку в виде какого-нибудь

class ManagedWrapper
{
    public event RakeEventHandler Rake
    {
        add
        {
            NativeMethods.AddCallbackTarget(value, GetContextForObject(value).ToIntPtr());
        }

        remove
        {
            NativeMethods.RemoveCallbackTarget(value, GetContextForObject(value).ToIntPtr());
        }
    }
}

и потом в коде

ManagedWrapper mw;

mw.Rake += MyHandler;

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

class ManagedWrapper
{
    public event RakeEventHandler Rake
    {
        add
        {
            SomeGlobalDelegateTable.Add(value);
            NativeMethods.AddCallbackTarget(value, GetContextForObject(value).ToIntPtr());
        }

        remove
        {
            NativeMethods.RemoveCallbackTarget(value, GetContextForObject(value).ToIntPtr());
            SomeGlobalDelegateTable.Remove(value);
        }
    }
}

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

WH>Я вот не помню ни одного случая когда отложенная инициализация имела смысл.

Случай простой — инициализация тяжёлая операция и не всегда нужная. Мне, например, не нравятся приложения стартующие 2-3 минуты потому что программист не стал заморачиваться и решил инициализировать всё сразу.

Здравствуйте, Константин Л., Вы писали:

КЛ>>>А это можно было и не говорить.
КЛ>>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
C>>То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.
КЛ>ну что за манера все доводить до абсурда?
Чтобы показать абсурдность твоей идеи.

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

КЛ>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
IT>А в чём проблема?

В том что если у тебя есть уровень1 в котором настраивается сущность, уровень2 которому на сущность начхать и уровень3 который использует сущность, то в результате изменения сущности надо переписывать уровень2.

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

IB>Да куда уж мне, только умоляю, пафос убери..

Ой, ну кто бы говорил. Ты себе аватарчик с нимбом уже заказал?

A>> класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;
IB>Ооох, Ромушка... =) Ну когда же ты хоть сам себя-то читать научишься? Здесь опять речь о порождающей иерархии.
IB>Более того, паттерн не обязательно должен удовлетворять всем пунктам из этого раздела. Это раздел о том, когда паттерн надо применять, а не описанеи паттерна.

Ещё раз, для особо одарённых.

класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;

речь о порождаемой иерархии.

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

IB>Хм.. У людей с адекватной самооценкой мой стиль изложения почему-то не вызывает негативной реакции.

Адекватная — это когда человек думает, что он глупее тебя? Я, в таком случае, чрезвычайно неадекватен.

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

IB>>Да куда уж мне, только умоляю, пафос убери..
A>Ой, ну кто бы говорил. Ты себе аватарчик с нимбом уже заказал?
Так он уже победил, просто это еще не так заметно