Лучший способ обеспечить доступ частного экземпляра к внешнему классу

Question

Прежде всего, не уверен насчет названия топи c здесь. Извините, если это действительно не соответствует тому, что я спрашиваю.

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

В настоящее время у меня есть один экземпляр A, который создает экземпляр другого класса B, и использует обратные вызовы из экземпляра B (через класс обратного вызова, который реализуется классом A), и использую этот обратный вызов для уведомить другой экземпляр класса C, также созданный внутри класса A и private. Вот сводная диаграмма:

Теперь в будущем по какой-то причине это еще один объект класса D, который необходимо создать и сохранить объект класса B. Проблема в том, что объект C по-прежнему необходимо уведомлять, когда у меня есть обратные вызовы от объекта B. И, конечно же, экземпляр C не может перейти от A к D. Таким образом, из D у меня нет ни экземпляра A, ни экземпляра B, и я не знаю, как лучше всего это сделать. Вот еще одна диаграмма с классом D:

Это в основном то же самое, что и первая диаграмма, за исключением последнего вызова (notifySomething ()) является гипотетическим, поскольку у меня нет доступа к C экземпляру из класса D.

Кто-нибудь когда-либо сталкивался с этой ситуацией и как лучше ее решить?

Спасибо!

Answer 1

A и D имеют одно задание: выполнить бизнес-логи c (когда вызываются их методы обратного вызова).

С учетом этого A и D пытаются выполнить три несвязанные задачи, которые им не принадлежат. Что-то еще (возможно, контейнер DI) должно взять на себя ответственность за эти задачи.

1. Управление зависимостями: A и D не должно заботиться о том, как создаются их зависимости. Что-то еще должно отвечать за создание экземпляра B. Создание не является работой A и D.
2. Регистрация слушателя: A и D не должно волновать, кто вызывает их методы обратного вызова. Что-то еще должно отвечать за регистрацию A и D до B. Регистрация не является работой A или D.
3. Уведомление слушателя: A и D не должно волновать, кому еще нужно уведомление от B. Что-то еще должно отвечать за регистрацию от C до B. Уведомление не является задачей A и D.

Одно решение ...

Отделите все управление созданием и зависимостями и регистрацию от других ваших объектов и поместите эту логику c в свое уникальное место. Это место называется композиция root вашего приложения, и ни один из ваших других объектов не должен пытаться выполнить работу композиции root.

Цель состоит в том, чтобы достичь инверсия зависимости .