Есть
ниткаАвтор: IB
Дата: 09.08.07
, чем плох Singleton и почему лучше в частности ISP, но там слишком много пунктов и дискуссии, поэтому я завожу новую ветку.
Итак, утверждается (среди прочих) два недостатка Singleton-a:
1. Зависимость обычного класса от синглтона не видна в публичном контракте класса, для выявления зависимости класса от синглтона надо залезть в тело каждого метода.
Ситуация: ISP передается в класс в параметрах, но ISP — это шляпа фокусника, откуда можно достать все что угодно — от кролика до инстанса класса. На конкретный
инстанс Singleton-a можно натравить Find All Reference в студии, та выдаст список и "залезть в тело каждого метода" не потребуется. С ISP это не пройдет: GetService() выдает некий класс, а что это за
инстанс — неизвестно.
Вопрос: и чем это лучше?
2. синглтон повышает связность
Похоже, имеется в виду связность двух классов друг с другом через синглетон. Правильно ли я понимаю, что имеется в виду ситуация, когда в обоих классах жестко прописано обращение к конкретному классу синглетона и что это даст сложности если потребуется сделать, чтобы класс:
а) вместо этого синглетона работал с другим?
б) мог работать с различными синглетонами?
Прошу сильно не бить — я и так запутался в своем бронепоезде...
Здравствуйте, Andrbig, Вы писали:
A>Итак, утверждается (среди прочих) два недостатка Singleton-a:
Попробую разобраться...
A>1. Зависимость обычного класса от синглтона не видна в публичном контракте класса, для выявления зависимости класса от синглтона надо залезть в тело каждого метода.
A>Ситуация: ISP передается в класс в параметрах, но ISP — это шляпа фокусника, откуда можно достать все что угодно — от кролика до инстанса класса. На конкретный инстанс Singleton-a можно натравить Find All Reference в студии, та выдаст список и "залезть в тело каждого метода" не потребуется. С ISP это не пройдет: GetService() выдает некий класс, а что это за инстанс — неизвестно.
A>Вопрос: и чем это лучше?
1. Если синглтон является сервисом, и таких сервисов-синглтонов может быть много, то использующий класс будет сложно повторно использовать.
Immobility
A design is immobile when it contains parts that could be useful in other systems, but the effort and risk involved with separating those parts from the original system are too great. This is an unfortunate but very common occurrence.
2. Если синглтон является сервис провайдером, то просто coupling будет сильнее, чем в случае передачи ISP в конструктор.
Декларировать зависимость от сервисов использующий класс может через исключения и документацию.
A>2. синглтон повышает связность
Из-за неточности перевода все времня путаются два понятния: связность (cohesion) и сопряжение (coupling). Наверное вы имели ввиду coupling...
A>Похоже, имеется в виду связность двух классов друг с другом через синглетон.
Между использующими классами может Semantic Coupling, но необязательно.
"Code Complete"
● Module2 uses global data after the global data has been modified by
Module1. This approach requires Module2 to assume that Module1 has
modified the data in the ways Module2 needs it to be modified, and that
Module1 has been called at the right time.
Между использующим классом и синглтоном обязательно Semantic Coupling.
A>Правильно ли я понимаю, что имеется в виду ситуация, когда в обоих классах жестко прописано обращение к конкретному классу синглетона и что это даст сложности если потребуется сделать, чтобы класс:
A>а) вместо этого синглетона работал с другим?
Да, сложность будет зависеть ок количества точек обращения к синглтону.
A>б) мог работать с различными синглетонами?
Если синглтон является сервисом?
A>Прошу сильно не бить — я и так запутался в своем бронепоезде...
У вас часом нет бороды и лысины?
Здравствуйте, Andrbig, Вы писали:
A>Есть ниткаАвтор: IB
Дата: 09.08.07
, чем плох Singleton и почему лучше в частности ISP, но там слишком много пунктов и дискуссии, поэтому я завожу новую ветку.
A>Итак, утверждается (среди прочих) два недостатка Singleton-a:
A>1. Зависимость обычного класса от синглтона не видна в публичном контракте класса, для выявления зависимости класса от синглтона надо залезть в тело каждого метода.
A>Ситуация: ISP передается в класс в параметрах, но ISP — это шляпа фокусника, откуда можно достать все что угодно — от кролика до инстанса класса. На конкретный инстанс Singleton-a можно натравить Find All Reference в студии, та выдаст список и "залезть в тело каждого метода" не потребуется. С ISP это не пройдет: GetService() выдает некий класс, а что это за инстанс — неизвестно.
A>Вопрос: и чем это лучше?
можно на лету заменить реализацию. причем можно использовать несколько реализаций одновременно. Кроме того, ISP это всего-лишь контейнер, dep. inj. предполагает мелькание в интерфейсе конкретных интерфейсов. Грубо говоря, где-то вверху из ISP выбирается все, что нужно, а потом распихивается куда нужно.
A>2. синглтон повышает связность
A>Похоже, имеется в виду связность двух классов друг с другом через синглетон. Правильно ли я понимаю, что имеется в виду ситуация, когда в обоих классах жестко прописано обращение к конкретному классу синглетона и что это даст сложности если потребуется сделать, чтобы класс:
A>а) вместо этого синглетона работал с другим?
A>б) мог работать с различными синглетонами?
типа того
A>Прошу сильно не бить — я и так запутался в своем бронепоезде...
дело в том, что IoC, при всей своей полезности, стал добычей маркетологов, и тут же появилось куча глашатаев со своим "ххх отстой". Для каждой конкретной ситуации нужно смотреть отдельно. В конце концов есть такая вещь, как детали реализации, когда ты совсем не хочешь публиковать в интерфейсе какие-то вещи. Так что я не стал бы быть столь категоричным. И для singleton'а найдется своё место.
