Плотно связанные классы: какой дизайн лучше в моей ситуации - PullRequest
Новая
       28

Плотно связанные классы: какой дизайн лучше в моей ситуации

1 голос
/ 23 января 2012

Какое решение лучше в моей ситуации, как спроектировать классы, чтобы они не были очень связаны?

У меня есть библиотека (API), которая предоставляет некоторые функции (например, подписка на потоковые цены FX методом subscribe). У меня есть клиент API, который сообщает API, какие цены он хочет получить. API обеспечивает обратную связь с некоторым интерфейсом (например, SubscriptionStatus) с методами SubscribeSuccess(Subscription) and SubscribeFailed(Subscription). В клиенте API у меня есть список активных подписок (List<Subscription> activeSubscriptions). И я хочу, чтобы клиент API реагировал только на успешную подписку (просто добавьте подписку в список). В остальных случаях - просто распечатать сообщение для входа. Как лучше всего организовать отношения между слушателем подписки и клиентом API? Варианты могут быть:

  1. Передать экземпляр клиента API подписчику, чтобы он мог вызвать apiClient.addSubscription(subscription)
  2. Клиент API реализует интерфейс SubscriptionStatus и управляет этими событиями (сбой, внутренний успех: activeSubscription.add (подписка)). Против: Есть много типов действий, и у каждого действия есть свой слушатель. Так что Api Client будет действительно большим классом.
  3. Определить собственный интерфейс одним методом SubscriptionSuccess(subscription) и позволить API-клиенту реализовать его?
  4. Ваш вариант?

Любые мысли по теме приветствуются!

Спасибо!

Ответы [ 2 ]

1 голос
/ 23 января 2012

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

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

throw UnsupportedOperationException("This method is not supported by your implementation of SubscriptionStatus. Please override it");

для каждого базового метода вместо пустой реализации.

Конечно, вы можете сохранить интерфейс SubscriptionStatus для правильного внедрения зависимостей и тестируемости, только сделайте BaseSubscriptionStatus реализовать это.

0 голосов
/ 23 января 2012

Я бы выбрал второй вариант. Это дало бы конечному пользователю максимальную гибкость и позволило бы более эффективно реагировать на проблемы с потоковой передачей в их ситуации.

...