Каковы преимущества цепочки ответственности по сравнению со списками классов?
Я бы поместил код в делегат viewWillAppear для каждого отображаемого представления:
Вот так, где вам нужно его скрыть:
- (void)viewWillAppear:(BOOL)animated
{
[yourObject hideBar];
}
Вот так где вам нужно показать это:
- (void)viewWillAppear:(BOOL)animated
{
[yourObject showBar];
}
3 ответа
Мне больше нравится ваша идея с коллекцией чем те преемники. Это упрощает и упрощает управление этим набором обработчиков: интерфейс коллекций хорошо известен, и все понимают, как выполнять итерацию по списку, а что нет.
Если вы используете этот способ преемника, предложенный другом, позаботьтесь о том, чтобы не впадают в очень глубокую рекурсию (если ваша платформа не поддерживает хвостовые вызовы, я не знаю, способны ли JVM на это).
Я бы не стал ' Рекомендую добавлять в коллекцию какие-либо методы. Вы получаете гораздо более сложный дизайн, который труднее понять и сложнее изменить. Есть две отдельные проблемы: хранение набора обработчиков и интерпретация этих обработчиков как цепочки ответственности. Метод, который обрабатывает запросы путем итерации по коллекции, находится на более высоком уровне абстракции, чем методы обслуживания коллекции, поэтому не должен принадлежать интерфейсу коллекции.
Какой подход лучше всего зависит от того, что хотят делать ваши обработчики.
Если обработчики могут полностью обрабатывать запрос-запрос самостоятельно, ваш подход подходит. У обработчиков нет ссылки на другие обработчики, что упрощает интерфейс обработчика. В отличие от стандартной реализации Chain of Responsibility, вы можете добавлять или удалять обработчики в середине цепочки. Фактически, вы можете создавать различные цепочки в зависимости от типа запроса.
Одна из проблем вашего подхода заключается в том, что обработчик не может выполнять предварительную или постобработку запроса. Если эта функция требуется, то лучше подойдет цепочка ответственности. В CoR обработчик отвечает за делегирование следующему обработчику в цепочке, поэтому обработчик может выполнять предварительную и / или постобработку, включая изменение или замену ответа от следующего обработчика в цепочке. В этом смысле CoR очень похож на Decorator; отличается просто намерение.
Поскольку в CoR обработчик сохраняет ссылку на следующий элемент в цепочке, вы не можете добавлять или удалять элементы из середины цепочки. Вариантом CoR, который позволяет вам добавлять или удалять элементы из середины цепочки, является цепочка фильтров (см., Например, javax.servlet.FilterChain ).
В примере кода, который вы показали, был набор операторов «если», которые выполняли различное поведение в зависимости от типа объекта. Если это типично для кода, который вы очищаете, вы можете просто иметь отображение типа запроса на требуемый обработчик.
Другой подход к удалению операторов «if» - это наследование. Если у вас есть какое-то поведение, которое вам нужно выполнить, и есть один вариант для веб-сервера и другой вариант для сервера SOAP, у вас могут быть WebServerRequestHandler и SoapServerRequestHandler, каждый из которых расширяет RequestHandler. Преимущество наследования в том, что там более четкое место для размещения логики, общей для обоих типов запросов. Недостатком является то, что, поскольку Java не имеет множественного наследования, вы можете моделировать только одномерные проблемы.
Не могу сказать, является ли цепочка ответственности вашим ответом, или даже применимо ли GoF. Посетитель может быть правильным. Недостаточно информации, чтобы быть уверенным.
Возможно, вашу проблему можно решить с помощью старого доброго полиморфизма. Или, может быть, карта, которая использовала ключи для выбора подходящего объекта-обработчика.
Помните, что нужно «делать как можно более простые вещи». Не бросайтесь к сложному, пока не докажете себе, что он вам нужен.
Недавно я прочитал о кампании Anti-IF , которая продвигает эту идею. Здесь звучит уместно.