Внедрение прямых объектных зависимостей или методов напрямую - PullRequest
1 голос
/ 03 мая 2011

Лучшая практика в DI, которую я читал в нескольких местах, - это не вводить объект B просто для того, чтобы добраться до объекта C, а вместо этого вводить C.

Но если единственный метод из C - это все, что требуется, вы бы просто внедрили этот метод вместо C?

Если так, то что, если потребуется несколько методов из C?Есть ли момент, когда просто удобнее передать весь объект и жить с тем фактом, что вы получаете вещи, которые вас не интересуют?

Или это указывает на то, что, возможно, в классе C слишком многоразличные обязанности и их нужно разделить на несколько небольших классов, объекты которых затем можно вводить без особого багажа?

Не бойтесь констатировать очевидное, для меня это все ново.

1 Ответ

3 голосов
/ 03 мая 2011

Если в зависимости есть (много) больше методов, чем вам нужно, это очень хороший признак того, что Интерфейс заголовка нарушает Принцип разделения интерфейса .

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...