Круговая зависимость с введением конструктора

Скажем, у меня есть следующие компоненты:

enter image description here

  • Производитель производит номера и отправляет сообщения потребителю
  • Как производитель, так и пользователи отправляют сообщения на монитор
  • Монитор, скажем произвольно, решает, когда процесс производства/потребления должен остановиться и отправит сообщение в "Стоппер"
  • Стопор останавливает работу обоих производителей и потребителей

Я знаю, что это легко выполнить на изменяемом языке, таком как Java. Я также знаю, что это можно решить, разрешив частичную изменчивость с интерфейсами, например, здесь.

Однако, не очень хорошая практика иметь циклические зависимости, даже если это возможно. Итак, пусть предполагается, что все ссылки инжектируются конструктором и final:

  • Производитель имеет final Consumer и final Monitor
  • Потребитель имеет final Monitor
  • Монитор имеет final Stopper
  • Стоппер имеет final Producer и final Consumer

Я нашел ссылки, такие как это, но они, похоже, не применяются.

Как можно было бы отключить этот случай и такие случаи, как это вообще? Другими словами, меня больше всего интересует, как добиться формирования циклов с дизайнерской точки зрения. Любые подсказки?

Ответ 1

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

Но могу ли я спросить, зачем их нужно вводить через конструктор? В конце концов нет ничего плохого, чтобы использовать setters для подключения beans.

Фактически, в Spring, beans обычно создаются сначала и вводятся впоследствии. Поэтому вы можете посмотреть на этот подход.

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

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

Или, как предлагает Тейлор, ESB.

Есть, вероятно, много других способов его разработки, читайте о (например) Apache Camel Enterprise Integration Patterns для некоторых идей.