Принципы объектно-ориентированного программирования

Question

Мне было интересно, я недавно прочитал статью, в которой говорилось о недостатках использования шаблона синглтона, определяющего недостаток возникновения глобальной переменной, и справедливо, что синглтон нарушает многие правила, которые мы изучаем в школе ООП, принцип единой ответственности, программированиек интерфейсам и абстрактным классам, а не к конкретным классам ... все это хорошо.Мне было интересно, как тогда вы работаете с таким классом соединений с базой данных, где вам нужно только одно соединение с вашей БД и один объект вашей БД.Автор говорил о принципе внедрения зависимости, который, на мой взгляд, хорошо согласуется с правилом обращения зависимости.Как я узнаю, какой объект передается как зависимость, кроме того факта, что я создал класс, и ожидаю, что все, кто его использует, будут играть хорошо и убедиться, что они используют правильный ресурс?!

Answer 1

Редактировать : В этом ответе предполагается, что вы используете контейнер внедрения зависимостей, либо тот, который вы написали самостоятельно, либо тот, который вы получили из библиотеки.Если нет, то используйте DI-контейнер:)

Как узнать, как управлять объектом, который передается как зависимость, кроме того факта, что я создал класс, и ожидать, что все, кто его использует, играют хорошо иубедиться, что они используют правильный ресурс?!

По контракту

Устный контракт - вы пишете спецификацию проекта, которая говорит: «Ты не должен создавать это экземплярнепосредственно к классу "и" не передавайте ни один объект, полученный из контейнера внедрения зависимостей. Если вам нужно, передайте контейнер ".

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

ISomething instance = serviceLocator.ResolveInstance<ISomething>(
  "TheInstanceImSupposedToUse");

Вы также можете сделать все ваши конкретные классы приватными /внутренняя / что-у-вас, и предоставьте им только абстрактный интерфейс для работы.Это не позволит им создавать экземпляры самих классов.

// This can only be instantiated by you, but can be used by them via ISomething
private class ConcreteSomething : ISomething
{
    // ...
}

Путем проверки кода

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

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

Если они нарушают ваши правила во время проверки кода, вы не разрешаете им регистрироваться, пока они не исправят свой код.По желанию, для повторных правонарушителей вы заставляете их платить вам доллар, заставляете их покупать обед или нанимаете другого подрядчика для их замены.Все, что хорошо работает в вашей группе:)

Answer 2

Для тех, кто критикует шаблон синглтона, основанный на SRP, вот противоположное представление .Кроме того, я обнаружил, что контейнеры для внедрения зависимостей могут создавать столько проблем, сколько они решают.Тем не менее, я использую многообещающий компромисс, как описано в другом посте .

Answer 3

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

Answer 4

Инъекционные контейнеры для зависимостей (даже те, которые вы разрабатываете сами, что не является чем-то необычным), как правило, очень настраиваемы.В этом сценарии вы должны сконфигурировать его так, чтобы любой запрос интерфейса, который реализует реализация, был бы удовлетворен этой реализацией.Даже если это синглтон.

Например, посмотрите на синглтон Logger, используемый здесь: http://www.pnpguidance.net/News/StructureMapTutorialDependencyInjectionIoCNET.aspx