Войти
ПрограммированиеФорумОбщее

Синглтон (Singleton) (комментарии) (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
11:54, 31 янв. 2014

aruslan, в ваших речах я вижу только эмоции и ничего более. У вас нет тезисов. Нет своей точки зрения.

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

Я приведу вам пример, как нужно толкать речи так, что бы в них был толк:

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

Это называется "выдвинуть тезис и обосновать его".

Первая часть сообщения - тезис. Вторая - обоснование тезиса. Вот что такое "точка зрения", которую можно принять или отвергнуть, но самое главное - её можно понять.

А пока вы не продемонстрируете ущербность техники и не предложите альтернативу, ваши речи - голословные "бла бла бла" в духе женщин: одни эмоции, и никакого толка.


#16
11:58, 31 янв. 2014

aruslan
> Не видел примеров удачного дизайна с синглтонами; возможно кому-то везет
> больше, ну или планка занижена.

вот вам пример:

os::file config = os::loadConfig("config.xml");

#17
12:01, 31 янв. 2014

Кстати, похоже IOC container правильно называть DI container (Dependency Injection Container). Хотя почему-то в любом случае гуглится то что нужно.

Так не у кого не было опыта использования DI container под С++? Какой хорошо себя показал?

#18
13:44, 31 янв. 2014

laMer007
вот моя попытка такого контейнера(без фабрики, считаю что это зло)

    namespace Helper
    {
        template<class T>
        inline T * getService( ServiceProviderInterface * _serviceProvider )
        {
            static T * s_service = nullptr;

            if( s_service == nullptr )
            {
                const char * serviceName = T::getServiceName();

                ServiceInterface * service = _serviceProvider->getService( serviceName );

#   ifdef _DEBUG
                if( dynamic_cast<T*>(service) == nullptr )
                {
          throw ServiceNotFoundExceptionT<T>();
                }
#   endif
                s_service = static_cast<T *>(service);
            }

            return s_service;
        }
    }

http://sourceforge.net/p/menge-engine/code/HEAD/tree/trunk/src/In… ceInterface.h

+

class RenderServiceInterface
  : public ServiceInterface
{
        SERVICE_DECLARE("RenderService")
...
};
#   define RENDER_SERVICE( serviceProvider )\
    (Menge::Helper::getService<Menge::RenderServiceInterface>(serviceProvider))
#19
13:52, 31 янв. 2014

IROV..
Ага, спасибо. DI container тоже зло как и синглтон? Или конкретно этот контейнер зло?

> ServiceProviderInterface
У сервис провайдера тоже может быть интерфейс? Можно что-нибудь для примера? Уже пример вижу в исходниках.

#20
13:59, 31 янв. 2014

IROV..
И как контейнер? Прижился? А сервис провайдеры хорошо себя показали?

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

#21
14:08, 31 янв. 2014

IROV..
Весьма своеобразный подход. Во многих случаях люди создают контейнер, который сам создает все объекты (в вашей терминологии сервисы) по описанию в правильном порядке в зависимости от зависимостей. Притом этот контейнер вызывает контейнеры с нужными параметрами конструктора или сам их после создания устанавливает различными способами (пока видел 2 способа: своей типа рефлексией, тк он знает часть содержимого объектов или сеттерами).
У вас получается объекты необходимо создавать вручную в правильном порядке. А объекты сами подергают и установят себе из сервис провайдера сервисы. Получается вся автоматика коту под хвост. Но да, цель свою действительно выполняет.

#22
14:17, 31 янв. 2014

Kartonagnick
Конкретно пока тестов нет во время работы приложения, то и проблем нет. Можно юзать синглтоны. В принципе даже если просто тесты есть, то уже будет много неприятного кода с синглтонами.

#23
15:14, 31 янв. 2014

IROV..
Прочитал про ваш метод. Пишут, что Service Locator is an Anti-Pattern.
Например http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/

#24
16:08, 31 янв. 2014

laMer007
> У вас получается объекты необходимо создавать вручную в правильном порядке. А
> объекты сами подергают и установят себе из сервис провайдера сервисы.
> Получается вся автоматика коту под хвост. Но да, цель свою действительно
> выполняет.
Я не смешиваю мух и котлет, то о чем вы говорите называется Bootstrapper и он скоро будет добавлен, не дошли руки еще

>>Прочитал про ваш метод. Пишут, что Service Locator is an Anti-Pattern.
А можно своими словами, что вы поняли, и почему посчитали что это Анти-Паттерн?

Мое мнение что это так-же эффективно разжижает моск и код как и синглетоны, но имеет ряд преимуществ перед ним, такие как четкий порядок создания-удаления(смотрим Holder) а также возможность передавать эти сервисы в другие модули(смотрим COM)

#25
16:10, 31 янв. 2014

laMer007
> И как контейнер? Прижился? А сервис провайдеры хорошо себя показали?
Да, в свое время очень спасли, особенно когда пришлось в Вин сборке добавлять дев-плагины, и туда нужно было передавать модули из энжайна, раньше каждый интерфейс передавался отдельно, что как вы говорите приносило большую попо-боль, при рефакторинге

#26
16:24, 31 янв. 2014

IROV..
> почему посчитали что это Анти-Паттерн?
Автор треда посчитал это антипаттерном из-за того что часть ошибок компиляции переносится на время выполнения. Например не совпали типы или отсутствует сервис зарегистрированный. Всё это выскочит во время выполнения. Также нет явной зависимости. Вот создаёте вы экземпляр класса и тут нужно прорыскать весь код класса чтобы понять какие зависимости этому классу требуются, а потом разобраться какие зависимости уже созданы и создать только нужные. Типа того. Потом вдруг надо поменять код и тут снова разборки с зависимостями чтобы не создать больше или меньше чем требуется на данном этапе.

#27
16:26, 31 янв. 2014

IROV..
> смотрим Holder
А где его там искать?

#28
16:28, 31 янв. 2014

IROV..
> раньше каждый интерфейс передавался отдельно

Service1 service1(service2, service3, service4, ...);
Так например приходилось?
#29
16:40, 31 янв. 2014

laMer007
> Например не совпали типы или отсутствует сервис зарегистрированный.
не совпадение типов - это проблема полиморфизма и даже за ошибку нельзя считать.
отсутствует сервис зарегистрированный - регулярно попадается, особенно когда добавляется новый сервис и забываешь их добавить в bootstrapper для разных платформ, но опять же это не ошибка.

> Вот создаёте вы экземпляр класса и тут нужно прорыскать весь код класса чтобы понять какие зависимости этому классу требуются, а потом разобраться какие зависимости уже созданы и создать только нужные.
А как по другому? Опять же я думаю это проблема bootstrapper`а ему будет дан список сервисов, и их зависимостей, смотрим Windows Services.

> > смотрим Holder
> А где его там искать?
Это аналог синглетона, только он не создает инстанс
Holder<T>::hold( new T );
T * t = Holder<T>::get();

>>Service1 service1(service2, service3, service4, ...);
>>Так например приходилось?
Да, и это демотивирует, когда нужно убрать или добавить новый сервис.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.