Как следует распространять общие ссылки в сборке?

Question

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

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

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

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

Answer 1

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

Шаблон контекстного объекта может принимать несколько форм.

Вы можете определить интерфейс, который имеет именно те элементы, которые вам нужны, или вы можете создать класс классов контейнеров. Например, при написании слабосвязанных компонентов, я имею тенденцию иметь, что каждый компонент, который я реализую, имеет соответствующий интерфейс, чтобы он мог быть переопределен, если это необходимо. Затем зарегистрировать объекты на «менеджер» объект, что-то вроде этого:

public interface IServiceManager 
{ 
    public T GetService<T>(); 
    public T RequireService<T>(); 
    public void RegisterService<T>(T service); 
    public void UnregisterService<T>(T service); 
} 

За кулисы есть карта от типа объекта, который позволяет мне очень быстро собрать большой набор различных компонентов в рабочий целое. Каждый компонент запрашивает другие по интерфейсу, а объект-менеджер - это то, что склеивает их вместе. (Если вы правильно автор ваших компонентов, вы можете даже выгрузить одну услугу для другого в то время как процесс запущен!)

Можно было бы зарегистрировать сервис что-то вдоль этих линий:

class FooService : IFooService { } 

// During process start-up: 
serviceManager.RegisterService<IFooService>(new FooService()); 

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

Answer 2

Я бы предложил передать в качестве параметра конструктор. Это имеет большое преимущество как для инъекций зависимостей, так и для проверки единиц измерения (издевательства).

Answer 3

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

• Он четко определяет фактические зависимости для класса - с «контекстом» вы не знаете, какие части контекста используются без копания в коде.
• Как правило, наличие большого количества параметров для конструктора представляет собой дизайнерский запах, поэтому использование инъекции конструктора помогает вам вынюхать недостатки дизайна.
• При тестировании вы можете издеваться индивидуальные зависимости в зависимости от того, чтобы издеваться целый Context