Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
AN>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, AlexNek, Вы писали:
G>>>>>Контейнер умеет управлять временем жизни объектов. Чтобы получить синглтон нужна одна строка конфига, использующий код не поменяется. AN>>>>Предположим был код AN>>>>
AN>>>>ErrorManagerSinglton.HandleError(e);
AN>>>>
AN>>>>каким образом он останется неизменным и как будет работать? G>>>Надо инжектить экземпляры ErrorManager в классы, а потом в конфиге сказать что должен быть один экземпляр ErrorManager. AN>>Вы все время говорите загадками. Я ведь не сижу в вашей голове. AN>>Каким образом получится абсолютно такой-же вызов? Откуда возьмется глобальный объект?
G>Используя IoC не будет синглтонов. Все вызовы будут идти для экземпляров объектов.
Если взять уже выложенный кусок то как будет инициализироваться errorManager? И как контейнер будет гарантировать один объект?
class FileImporter
{
private ErrorManager errorManager;
public void importFile(File f)
{
...
catch(Exception e)
{
errorManager.HandleError(e);
}
...
}
}
Здравствуйте, AlexNek, Вы писали:
AN> Если взять уже выложенный кусок то как будет инициализироваться errorManager? И как контейнер будет гарантировать один объект?
The core principal is to separate behaviour from dependency resolution.
Почитай http://code.google.com/p/google-guice/wiki/Motivation?tm=6
Для C# не знаю... может кто-нибудь что-нибуддь порекомендует?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>Там как раз таки есть синглтон.
G>>Это не синглтон ни разу.
AVK>Ага, не верь глазам своим.
G>>1) У HttpContext есть публичный конструктор. То есть не является единственной точкой входа. AVK>Это не изначает, что это не синглтон.
G>>2) HttpContext.Current не является глобальным объектом и предназначен именно для того чтобы получить текущий контекст, а не "единственный экземпляр глобального объекта". AVK>Забавная софистика.
Тем не менее. Синглтон — объект с единственным экземпляром. HttpContext не имеет единственного экземпляра.
"Единая точка входа" (хотя странно звучит такая формулировка для большого количества объектов) в виде HttpContext.Current не сильно нужна, так как контекст передается в IHttpModule\IHttpHandler.
Так что HttpContext.Current — не более чем шорткат для быстрой разработки.
AVK>>> А именно HttpContext.Current. И из-за этого самого синглтона МС пришлось изрядно поплясать с бубном несколько позже. G>>Ты о чем?
AVK>К примеру, HttpApplicationStateBase, думаешь, от хорошей жизни пришлось добавить?
А это тут причем? Недостаток DIP является следствием синглтона, но не причиной.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>>>нет, он не должен быть синглтоном. Посмотри на кеширование в asp.net, там нет синглтонов.
L>>>Это ответ на какой-то другой вопрос. Я спрашивал, почему "синлтон должен быть stateless", а не "может ли CacheManager быть не singleton-ом" G>>Ну так ты привел не подходящий для синглтона тип.
L>Тип вполне подходящий, от того, что возможна другая реализация, вовсе не следует, что первоначальная реализация не подходит.
В чем это они подходящий? Как такой синглтон протестировать? Я вот как раз обратный пример в ASP.NET вижу.
G>>>>Причиной сложностям является злостное нарушение SRP синглтоном. С одной стороны он предоставляет функционал, с другой стороны является единственной точкой входа в этот функционал.
L>>>Мне кажется, тут идет смешение понятий 1) singlton-а как объекта, которые может существовать только в одном экземпляре 2) реализации singlton-а, предложеной в GoF.
G>>Чтобы объект существовал в единственном экземпляре надо G>>1) Не иметь публичного конструктора G>>2) Уметь получать экземпляр
G>>Если попробовать сделать все в одном классе, то получится GoF-синглтон.
G>>Я же говорю что нет смысла объединять решение этих двух задач.
L>Под singleton-ом я прежде всего имел в виду объект, которые может существовать исключительно в одном экземпляре.
А я выше не что-то другое написал? См выделенное
L>Реализация, предложенная в GoF — одна из возможных, можно сделать так, можно и путем выноса функционала в фабрику.
В отсутствии friend-классов в .NET честными способами сделать не получится. Или ты просто теряешь гарантию единственности экземпляра.
L>Есть какие-нибудь причины, почему такой синглтон обязательно должен быть stateless?
Да, причина в этой теме. Хрен протестируешь.
Здравствуйте, AlexNek, Вы писали:
G>>Используя IoC не будет синглтонов. Все вызовы будут идти для экземпляров объектов. AN>Если взять уже выложенный кусок то как будет инициализироваться errorManager? И как контейнер будет гарантировать один объект?
Здравствуйте, gandjustas, Вы писали:
L>>>>Мне кажется, тут идет смешение понятий 1) singlton-а как объекта, которые может существовать только в одном экземпляре 2) реализации singlton-а, предложеной в GoF.
G>>>Чтобы объект существовал в единственном экземпляре надо G>>>1) Не иметь публичного конструктора G>>>2) Уметь получать экземпляр
G>>>Если попробовать сделать все в одном классе, то получится GoF-синглтон.
G>>>Я же говорю что нет смысла объединять решение этих двух задач.
L>>Под singleton-ом я прежде всего имел в виду объект, которые может существовать исключительно в одном экземпляре. G>А я выше не что-то другое написал? См выделенное
Ты написал как реализовать singleton, а не что это такое.
L>>Реализация, предложенная в GoF — одна из возможных, можно сделать так, можно и путем выноса функционала в фабрику. G>В отсутствии friend-классов в .NET честными способами сделать не получится. Или ты просто теряешь гарантию единственности экземпляра.
Получится. Навскидку 2 варианта:
1. фабрика и тип синглтона в отдельной сборке + internal конструктор.
2. синглтона в статическом конструкторе регистрирует в фабрике callback создания себя.
Не говоря уж о рефлексии.
L>>Есть какие-нибудь причины, почему такой синглтон обязательно должен быть stateless? G>Да, причина в этой теме. Хрен протестируешь.
Еще раз задам вопрос, похоже ты его не понял:
Пусть есть объект, который должен существовать в приложении в одном и только одном экземпляре. Если ли какие-то причины, почему этот объект должен быть stateless.
Вопрос конструирования такого объекта оставим в стороне.
Здравствуйте, Lloyd, Вы писали:
L>>>Реализация, предложенная в GoF — одна из возможных, можно сделать так, можно и путем выноса функционала в фабрику. G>>В отсутствии friend-классов в .NET честными способами сделать не получится. Или ты просто теряешь гарантию единственности экземпляра.
L>Получится. Навскидку 2 варианта: L>1. фабрика и тип синглтона в отдельной сборке + internal конструктор. L>2. синглтона в статическом конструкторе регистрирует в фабрике callback создания себя.
Где гарантия что другой класс этой же сборки юзает именно этот экземпляр?
У тебя не синглтон получился, а "верьте что это синглтон".
L>>>Есть какие-нибудь причины, почему такой синглтон обязательно должен быть stateless? G>>Да, причина в этой теме. Хрен протестируешь.
L>Еще раз задам вопрос, похоже ты его не понял: L>Пусть есть объект, который должен существовать в приложении в одном и только одном экземпляре. Если ли какие-то причины, почему этот объект должен быть stateless.
Ты похоже не понял что ты сам описал не синглтон.
Есть две большие разницы между "объекты должен существовать в приложении в одном и только одном экземпляре" и "все используют один экземпляр объекта". Снаружи эффект одинаковый, внутренности заметно различаются.
Так вот синглтон должен быть stateless, иначе тестировать не получится. Объект, один экземпляр которого используют все, не обязан быть синглтоном.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Если взять уже выложенный кусок то как будет инициализироваться errorManager? И как контейнер будет гарантировать один объект? .>The core principal is to separate behaviour from dependency resolution. .>Почитай http://code.google.com/p/google-guice/wiki/Motivation?tm=6 .>Для C# не знаю... может кто-нибудь что-нибуддь порекомендует?
.>Если останутся вопросы — спрашивай.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Каким образом, где и когда? Как достучаться до контейнера? .>До контейнера не надо стучаться, принцип IoC как раз и говорит, что его не зовут, а он сам приходит когда надо.
Звучит как фантастика, но что то не не нашел пока примера где контейнер не есть синглтон.
AN>> Кто даст гарантию правильной инициализации errorManager? .>Контейнер. Уж явно это не дело это errorManager-а.
Ну если он является синглтоном это не удивительно. Значит достаточно переименовать "синглотон" на "IOS контейнер" и задача решена — вуаля.
AN>> Что делать если он не иницилизирован по какой либо причине? .>Падать с громким грохотом.
угу, и крепко сжав губы молчим.
AN>> .>Для тестов можно их создавать несинглтонно. AN>> .>Ведь самому FileImporter совершенно по барабану сколько реально экземпляров ErrorManager существует, вот и не надо заставлять класс делать то, что ему делать не положено. AN>> Он всего лишь вызывает "глобальную функцию". .>Такие функции могут быть только чистыми. Им снова по барабану сколько экземпляров существует.
Примерчик: хотим записывать лог в базу, но если база не доступна пишем в файл, если файл недоступен пишем на консоль.
Эта чистая функция?
Здравствуйте, gandjustas, Вы писали:
L>>>>Реализация, предложенная в GoF — одна из возможных, можно сделать так, можно и путем выноса функционала в фабрику. G>>>В отсутствии friend-классов в .NET честными способами сделать не получится. Или ты просто теряешь гарантию единственности экземпляра.
L>>Получится. Навскидку 2 варианта: L>>1. фабрика и тип синглтона в отдельной сборке + internal конструктор. L>>2. синглтона в статическом конструкторе регистрирует в фабрике callback создания себя. G>Где гарантия что другой класс этой же сборки юзает именно этот экземпляр?
В каком из этих вариантов?
G>У тебя не синглтон получился, а "верьте что это синглтон".
Ты не понимаешь, что такое singleton.
Даже вариант из GoF не дает 100% гарантий:
1. всегда можено сериализовать/десериализовать объкет
2. всегда можно создасть неинициализированный объект.
L>>>>Есть какие-нибудь причины, почему такой синглтон обязательно должен быть stateless? G>>>Да, причина в этой теме. Хрен протестируешь.
L>>Еще раз задам вопрос, похоже ты его не понял: L>>Пусть есть объект, который должен существовать в приложении в одном и только одном экземпляре. Если ли какие-то причины, почему этот объект должен быть stateless. G>Ты похоже не понял что ты сам описал не синглтон.
Я прекрасно понял, что я имею в виду. А вот до тебя мысль донести не удается.
G>Есть две большие разницы между "объекты должен существовать в приложении в одном и только одном экземпляре" и "все используют один экземпляр объекта". Снаружи эффект одинаковый, внутренности заметно различаются.
Пожалуйста, открой GoF и посмотри наконец, что такое singleton.
singleton — это объект который может существовать не более чем в одном экземпляре.
В этом определении нет никакого упоминания способ получения такого экземпляра.
Да, в книге описывается способ, как можно этого достичь на уровне кода, но этот способ не является определяющим для singleton-а.
Например, можно админимтративно под угрозой увольнения в трудовом договоре запретить пользоваться открытым конструктором — тоже способ гарантировать единственность экземпляра.
G>Так вот синглтон должен быть stateless, иначе тестировать не получится. Объект, один экземпляр которого используют все, не обязан быть синглтоном.
Тестировать синглтон не получится вне зависимости есть у него состояние или нет.
Причем тут stateless? Где связь?
Здравствуйте, AlexNek, Вы писали:
AN> Чем это отличается от синглтона?
Ничем. Это показан "обычный" код, описаны его недостатки и предложена альтернатива. Ты текст-то читал?
Здравствуйте, AlexNek, Вы писали:
AN> Звучит как фантастика, но что то не не нашел пока примера где контейнер не есть синглтон.
В test suite, например, почти наверняка.
AN> Ну если он является синглтоном это не удивительно. Значит достаточно переименовать "синглотон" на "IOS контейнер" и задача решена — вуаля.
Если у тебя во всём коде есть ровно один синглтон и ты его никогда сам напрямую не используешь, то да, вуаля.
AN> угу, и крепко сжав губы молчим.
? Оно просто упадёт во время старта, во время загрузки контекста.
AN> .>Такие функции могут быть только чистыми. Им снова по барабану сколько экземпляров существует.
AN> Примерчик: хотим записывать лог в базу, но если база не доступна пишем в файл, если файл недоступен пишем на консоль. AN> Эта чистая функция?
Если этот лог — бизнес операция, то, конечно, это сервис, а не глобальная функция. Если просто логгирование кода, то думаю большинство достаточно развитых logging frameworks такое умеют делать, читая описание из конфига.
Здравствуйте, Lloyd, Вы писали:
L>>>Получится. Навскидку 2 варианта: L>>>1. фабрика и тип синглтона в отдельной сборке + internal конструктор. L>>>2. синглтона в статическом конструкторе регистрирует в фабрике callback создания себя. G>>Где гарантия что другой класс этой же сборки юзает именно этот экземпляр? L>В каком из этих вариантов?
В обоих.
G>>У тебя не синглтон получился, а "верьте что это синглтон". L>Ты не понимаешь, что такое singleton.
Ага, конечно.
L>Даже вариант из GoF не дает 100% гарантий: L>1. всегда можено сериализовать/десериализовать объкет L>2. всегда можно создасть неинициализированный объект.
"Всегда" это во взрослом .NET FW с fulltrust, далеко не всегда получается.
L>>>>>Есть какие-нибудь причины, почему такой синглтон обязательно должен быть stateless? G>>>>Да, причина в этой теме. Хрен протестируешь.
L>Пожалуйста, открой GoF и посмотри наконец, что такое singleton. L>singleton — это объект который может существовать не более чем в одном экземпляре.
А я что-то другое пишу?
L>В этом определении нет никакого упоминания способ получения такого экземпляра.
Да что ты? А как обеспечить всегда существование не более одного экземпляра и получение единственного экземпляра?
Синглтон это гарантия для вызывающего кода, выраженная в интерфейсе класса. Иначе пустой треп получается.
L>Да, в книге описывается способ, как можно этого достичь на уровне кода, но этот способ не является определяющим для singleton-а.
Ты сам себе противоречишь. Если можно таки получить более одного экземпляра честным способом, то это уже не синглтон, потому что более одного экземпляра.
L>Например, можно админимтративно под угрозой увольнения в трудовом договоре запретить пользоваться открытым конструктором — тоже способ гарантировать единственность экземпляра.
Это уже к архитектуре не относится.
G>>Так вот синглтон должен быть stateless, иначе тестировать не получится. Объект, один экземпляр которого используют все, не обязан быть синглтоном. L>Тестировать синглтон не получится вне зависимости есть у него состояние или нет. L>Причем тут stateless? Где связь?
Если состояния нет, то тестировать отлично получается.
Здравствуйте, gandjustas, Вы писали:
G>Еще раз: состояние синглтона должно выставляться один раз, независимо от контекста использования. Если это не так, то скорее всего надо отказаться от синглтона.
Может быть, еще и цитату из GoF приведешь — что-то я не припомню чтобы там шла речь про "должно".
Здравствуйте, gandjustas, Вы писали:
G>Так что HttpContext.Current — не более чем шорткат для быстрой разработки.
Ну вот из-за этого шортката и имеем синглтонный геморой в полный рост.
AVK>>К примеру, HttpApplicationStateBase, думаешь, от хорошей жизни пришлось добавить? G>А это тут причем?
А это как раз следствие увлечения статиками в первой версии asp.net.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, Lloyd, Вы писали:
L>Статические функции сложнее мокать
T Foo() {
SomeClass::Foo();
}
И использовать Foo() при разработке / тестировании. Имхо, это будет сложнее в использовании, если в проекте более 50-100 статических метод, нуждающихся в тестировании.
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, gandjustas, Вы писали:
G>>Еще раз: состояние синглтона должно выставляться один раз, независимо от контекста использования. Если это не так, то скорее всего надо отказаться от синглтона.
W>Может быть, еще и цитату из GoF приведешь — что-то я не припомню чтобы там шла речь про "должно".
Это не в GoF, это в практике использования и тестирования синглтонов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Так что HttpContext.Current — не более чем шорткат для быстрой разработки.
AVK>Ну вот из-за этого шортката и имеем синглтонный геморой в полный рост.
Синглтоны тут не при чем.
AVK>>>К примеру, HttpApplicationStateBase, думаешь, от хорошей жизни пришлось добавить? G>>А это тут причем?
AVK>А это как раз следствие увлечения статиками в первой версии asp.net.
