Избежание переноса зависимости

Question

При кодировании я часто сталкиваюсь со следующей схемой:

- Метод вызывает другой метод (Fine), но вызываемый метод / callee принимает параметры, поэтому в методе переноса я передаю параметры. Проблема в том, что эта зависимость может продолжаться и продолжаться. Как я мог избежать этого (любой пример кода приветствуется)?

Спасибо

Answer 1

Передача параметра только потому, что компоненту нижнего уровня требуется, это признак Leaky Abstraction . Зачастую рефакторинг зависимостей может быть более эффективным для агрегирования сервисов и скрытия каждой зависимости за интерфейсом.

Сквозные проблемы (которые часто являются наиболее распространенной причиной передачи параметров) лучше всего решать декораторам .

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

Answer 2

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

Шаг 2: Добавьте геттеры в класс X, чтобы получить соответствующую информацию. Вызываемый должен использовать получатели для получения информации, а не полагаться на параметры.

Шаг 3. Создайте интерфейсный класс, наследуемый классом X. Поместите все геттеры в интерфейс (в C ++ это как чисто виртуальные методы).

Шаг 4. Сделайте так, чтобы вызываемые методы зависели только от интерфейса.

Answer 3

Вы можете использовать структуру внедрения зависимостей. Одним из таких является Guice: см. http://code.google.com/p/google-guice/

Answer 4

Рефакторинг: введите объект параметра

У вас есть группа параметров, которые естественным образом совпадают?

Замените их объектом.

http://www.refactoring.com/catalog/introduceParameterObject.html

Преимущество объекта параметров заключается в том, что передаваемые им вызовы не нужно изменять, если вы добавляете / удаляете параметры.

(учитывая контекст ваших ответов, я не думаю, что библиотека IoC или шаблоны внедрения зависимостей действительно то, что вам нужно)

Answer 5

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

Может ли внедрение зависимостей предотвратить циклическую зависимость?