Здравствуйте, COFF, Вы писали:
COF>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение.
А может сделаем все данные глобальными ? Знаете как удобно!!! и тащить не надо не в один модуль!
Здравствуйте, COFF, Вы писали:
COF>На самом деле это не так, достаточно в классе синглетона иметь методы CreateInstance/DestroyInstance и GetInstance. CreateInstance вызывается логическим владельцем синглетона, а GetInstance всеми остальными клиентами. При этом клиент должен быть готов, что GetInstance может провалиться, хотя на практике это обозначает, что объект-синглетон создается/уничтожается в неправильном месте. Это же позволяет решить тонкие проблемы с доступом из разных потоков — CreateInstance вызывается до создания первого рабочего потока, а DestroyInstance — после удаления последнего. В качестве синглетонов у меня обычно оформляются фасады подсистем. Например, очень хорошо срабатывает это в случае System Layer.
Ну метод CreateInstance живет в синглетоне, правильно? Перемести этот CreateInstance в другой класс и все будет намного проще. А делать фасад к подсистеме в виде синглетона — это жестоко. Сначала думаем, как бы нам систему разбить на слабо-связанные подсистемы, а потом надежно приколачиваем одну подсистему к другой синглетонами.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, COFF, Вы писали:
COF>>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение.
M>А может сделаем все данные глобальными ? Знаете как удобно!!! и тащить не надо не в один модуль!
А может поименуем все-все объекты в программе, положим их в контейнер и любое обращение будем делать через него? Знаете как гибко!!!
MVK>Ну метод CreateInstance живет в синглетоне, правильно? Перемести этот CreateInstance в другой класс и все будет намного проще. А делать фасад к подсистеме в виде синглетона — это жестоко. Сначала думаем, как бы нам систему разбить на слабо-связанные подсистемы, а потом надежно приколачиваем одну подсистему к другой синглетонами.
Я же не говорю, что всегда надо так делать Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса. Предположим, я хочу сделать логгирование. В варианте с синглетоном я делаю трейд-офф и получаю простой и быстрый доступ к логу взамен на довольно неопределенные перспективы появления нескольких объектов логгирования в будущем. В варианте без синглетона появляется необходимость включать ссылку на лог или на контейнер в интерфейс класса (т.е. происходит по сути глобальное зацепление всех классов на класс лога/контейнера), при этом в варианте с контейнером каждая запись в лог — это поиск по контейнеру, потом динамическое приведение типов. Положим, если я пишу на яве, объектов в контейнере немного и лог сразу скидывается в файл, то это не критично, но на C++ и записи в память — это может быть довольно затратно, например если лог используется для профилирования. Потом, в варианте с синглетонов мне никто не запрещает открывать и другие логи по необходимости.
Да, под подсистемами я как раз и имел в виду что-то общесистемное типа лога. Например, я могу создать интерфейс записи в файл, сделать его синглетоном и все обращения к файловой системе делать только через него.
Здравствуйте, COFF, Вы писали:
COF>Я же не говорю, что всегда надо так делать Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса.
Это тоже уровень интерфейса, только неявный.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
COF>>Я же не говорю, что всегда надо так делать Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса. AJD>Это тоже уровень интерфейса, только неявный.
В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда . Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
COF>>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение. WH>Протащить контекст гораздо проще и дешевле чем разбиратся с теми макаронами что случаются из-за применения синглетонов.
Интересно. И что — таскаете логгеры повсюду? Лично я ни разу такого не видел. Всегда считал что подсистема логгирования — это единственный достойный кандидат на имплементацию синглтоном, во всех остальных случаях синглтон это красивый расписной титановый костыль для кривоногой программы.
Здравствуйте, Left2, Вы писали:
L>Интересно. И что — таскаете логгеры повсюду? Лично я ни разу такого не видел.
Таскаю я их конечно не по отдельности, а в некотором контейнере.
L>Всегда считал что подсистема логгирования — это единственный достойный кандидат на имплементацию синглтоном, во всех остальных случаях синглтон это красивый расписной титановый костыль для кривоногой программы.
Например у меня сейчас 3 логгера. На следующей неделе скорей всего добавлю еще один.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
L>>Интересно. И что — таскаете логгеры повсюду? Лично я ни разу такого не видел. WH>Таскаю я их конечно не по отдельности, а в некотором контейнере.
Ну просто в более-менее большой системе как правило куча классов, и большинство из них хоть что-то да выплёвывают в лог. К примеру, есть у тебя класс SMSSender, который отсылает SMS. Ты ему явно в конструкторе передаёшь логгер? Или там к примеру есть какие-то свои контейнеры — они тоже логгер принимают в конструкторе? А если обьект небольшой (смартпоинтер из С++), но ему нужен логгер — ты идёшь на увеличение размера обьекта только для того чтобы он всегда знал свой логгер?
Здравствуйте, Left2, Вы писали:
L>Ну просто в более-менее большой системе как правило куча классов, и большинство из них хоть что-то да выплёвывают в лог. К примеру, есть у тебя класс SMSSender, который отсылает SMS. Ты ему явно в конструкторе передаёшь логгер?
См Re[3]: Singleton против static class c# 2
L>Или там к примеру есть какие-то свои контейнеры — они тоже логгер принимают в конструкторе?
Какие еще контейнеры?
L>А если обьект небольшой (смартпоинтер из С++), но ему нужен логгер — ты идёшь на увеличение размера обьекта только для того чтобы он всегда знал свой логгер?
Зачем смартпоинтеру логгер?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Грамотно, решение нравится Видел такой подход в COM, но тогда не оценил глубины идеи.
L>>Или там к примеру есть какие-то свои контейнеры — они тоже логгер принимают в конструкторе? WH>Какие еще контейнеры?
Ну свой MyCoolContainer, к примеру. MyVector там или MyMultiMap.
L>>А если обьект небольшой (смартпоинтер из С++), но ему нужен логгер — ты идёшь на увеличение размера обьекта только для того чтобы он всегда знал свой логгер? WH>Зачем смартпоинтеру логгер?
Да логгер по большому счёту всем нужен. Если система большая и сложная — то рано или поздно практически все классы начнут хотеть писАть в лог. Но в принципе конечно умерить аппетиты классов, разбив их на "утилитные классы которые всегда работают и в лог ничего не пишут потому что они уже отлажены и ломаться в них нечему" и "классы бизнес-логики которые могут поломаться и логгер для них необходим" вполне возможно и даже наверное полезно
Здравствуйте, COFF, Вы писали:
COF>В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда.
"Теоретически — наверное, да." (c) . Практически это вылевается в жуткий геморрой.
COF>Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
Но просто надо не забывать, что наследование — это самый высокий тип связанности (coupling).
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Left2, Вы писали:
L>Ну свой MyCoolContainer, к примеру. MyVector там или MyMultiMap.
А зачем им логгер?
L>Да логгер по большому счёту всем нужен. Если система большая и сложная — то рано или поздно практически все классы начнут хотеть писАть в лог.
Если задумыватся о проектировании не начнут.
L>Но в принципе конечно умерить аппетиты классов, разбив их на "утилитные классы которые всегда работают и в лог ничего не пишут потому что они уже отлажены и ломаться в них нечему" и
Во-во. Один раз написал смартпоинтер или контейнер какойнибудь, обложил юниттестами и все.
L>"классы бизнес-логики которые могут поломаться и логгер для них необходим" вполне возможно и даже наверное полезно
А им наверняка нужны будут еще и другие сервисы и контекст тянуть по любому...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, COFF, Вы писали:
COF>В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда . Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
Мне кажется вы совсем не про сингелтон говорите, а про глобальную точку входа.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, COFF, Вы писали:
COF>>В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда . Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
M>Мне кажется вы совсем не про сингелтон говорите, а про глобальную точку входа.
То же самое, вид сбоку Зайдите на гугл и наберите global access point pattern
Здравствуйте, WolfHound, Вы писали:
WH>Когда я говорю 2 логгера я говорю не два объекта, а два разных логгера. С разными настройками, с разным уровнем логгирования, с разными файликами куда все пишется,...
Это плохой пример и дело даже не в синглтоне, а в том, что ты фильтрацию сообщений выносишь за пределы системы журналирования и вместо того чтобы настроить "эти сообщения в первый журнал, эти во второй, эти в оба" начинаешь писать велосипеды. Вместо того чтобы управлять через конфиги, начинаешь писать if'ы. В этом смысле да, логгер должен быть один, а будет ли это синглтон уже отдельный вопрос.
ИМХО пусть будет, потому что если мне журналирование нужно, то у меня в любом случае будет зависимость на некоторую Logger.dll и я от динамики только проигрываю. Мне удобнее написать Logger.Log("message") понимая, что иногда сообщение вообще никуда не будет записано, чем каждый раз получать его из IServiceProvider, заодно проверяя а не null ли результат.
Здравствуйте, WolfHound, Вы писали:
WH>Протащить контекст гораздо проще и дешевле чем разбиратся с теми макаронами что случаются из-за применения синглетонов. WH>Просто решение само по себе получается гораздо болие гибким.
Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null). Смысла в этом решительно никакого нет, код пухнет, смысла не добавляется. IServiceProvider имеет смысл использовать только как контейнер для передачи опциональных зависимостей. Причём достаточно неудобный контейнер, так как невозможно передать два однотипных объекта. возвращаясь к твоему примеру, ты не можешь передать два ILogger через IServiceProvider, и даже два FileLogger тоже не сможешь.
Объязательные зависимости конфигурируемые снаружи передаются вно, типизированными параметрами. объязательные зависимости не конфигурируемые снаружи (журналирование), особенно общие для нескольких компонент, надо делать синглтонами. Так лгче их поддерживать. Если у меня, например, есть две библиотеки, для SMTP и POP3, то мне удобнее не грузить приложение тем, что они что-то журналируют, пусть сами получают логеер-синглтон. Заодно я точно буду знать, что какой-нибудь гений неразобравшись не создаст им два разных экземпляра синглтона журналирования, хотя реальная фильтрация производится не рна уровне объектов, а на уровне источника сообщения "network.tcp.client.smtp", "network.tcp.client.pop3"
Здравствуйте, WolfHound, Вы писали:
L>>Да логгер по большому счёту всем нужен. Если система большая и сложная — то рано или поздно практически все классы начнут хотеть писАть в лог. WH>Если задумыватся о проектировании не начнут.
Это смешно, делать подобные утверждения. На самом деле ты увеличиваешь связность.
К примеру, реальная ситуация. Делаю систему отслыки почтовых сообщений, всё многократно протестированно, всё хорошо. В некоторой далёкой стране, есть старый почтовый сервер не поддерживающий RFC. Программа с ним не работает. То есть по твоей логике мне надо либо перелопатить всё сверху до низу, чтобы с верхнего уровня протащить в SmtpClient объект-логгер? Зачем? У меня логгер — синглтон. Изменил код только в том месте, где реально понадобилось журналирование. Отослал кастом-билд, узнал, что не поддерживается команда EHLO и надо пользовать устаревшую HELO. На всё ушли сутки. Если бы мне пришлось протаскивать логгер через все уровни, ушло бы гораздо больше времени. Плюс, по факту решения проблемы, я журналирования из исходников потёр. Тоже без последствий для вышестоящих уровней. А проносить все зависимости сверху до ниху практика весьма и весьма плохая.
Здравствуйте, adontz, Вы писали:
A>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null).
А для этого нужно использовать для создания объектов фабрики, которые автоматически разрешают нужные зависимости.
Здравствуйте, Cyberax, Вы писали:
A>>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null). C>А для этого нужно использовать для создания объектов фабрики, которые автоматически разрешают нужные зависимости.
В итоге ты опять получишь синглтон, только в крайне извращённой форме. Правой рукой левое ухо...
Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса. Предположим, я хочу сделать логгирование. В варианте с синглетоном я делаю трейд-офф и получаю простой и быстрый доступ к логу взамен на довольно неопределенные перспективы появления нескольких объектов логгирования в будущем. В варианте без синглетона появляется необходимость включать ссылку на лог или на контейнер в интерфейс класса (т.е. происходит по сути глобальное зацепление всех классов на класс лога/контейнера), при этом в варианте с контейнером каждая запись в лог — это поиск по контейнеру, потом динамическое приведение типов. Положим, если я пишу на яве, объектов в контейнере немного и лог сразу скидывается в файл, то это не критично, но на C++ и записи в память — это может быть довольно затратно, например если лог используется для профилирования. Потом, в варианте с синглетонов мне никто не запрещает открывать и другие логи по необходимости.
