Каковы известные «ошибки» в отношении цепочки ответственности?

Question

Я обнаружил, что часто использую шаблон Цепочка ответственности (3 раза для меня) в моем текущем проекте, и мне интересно, не стал ли я слишком увлечен решением , В частности, я использовал цепной проект Apache Commons . Итак, я был весьма впечатлен тем, как он упростил ряд сложных взаимозаменяемых частей логики приложения в более связное и организованное целое. Тем не менее, некоторым новичкам в проекте, кажется, трудно «получить его». Каков ваш опыт с этим? С какими проблемами вы столкнулись при его реализации?

Пока единственная проблема, которую я заметил, это когда вы пытаетесь иметь дело с объектами, которые должны быть закрыты. Хранение этих объектов в вашем классе Context делает боль, когда вы завершили выполнение своей цепочки. Мне удалось обойти это, используя Фильтры вместо Команд, но это кажется немного не интуитивным, потому что ваши операторы close часто очень далеко от того, где был создан объект.

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

Заранее спасибо.

Answer 1

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

Опасность шаблона «Цепочка ответственности» практически такая же, как и для шаблона «Классная доска»: в конечном итоге действительно легко создать множество абстракций, которые в основном не обеспечивают ценность в достижении конечной цели. Командные объекты и объекты обработки на самом деле просто скрывают логику вашего приложения за цепочкой обработки, а не помещают ее прямо туда, где находится ваш самый важный код. Это гораздо легче понять и поддерживать, если вы просто запрограммируете метод (или несколько методов), который представляет полную цепочку обработки без абстракций цепочки обработки. Цепочка обработки действительно может скрыть бизнес-логику вашего приложения, и я думаю, что вы отдаете предпочтение техническому артефакту над бизнес-кодом.

Таким образом, в основном вы заменяете то, что могло бы быть очень простым кодом приложения, который очень легко читает гораздо более абстрактными цепочками обработки. Вы занимаетесь метапрограммированием. Лично я никогда больше не занимаюсь метапрограммированием, поэтому я склонен согласиться с теми коллегами, которым это не нравится. ;)

Answer 2

Я думаю, что было бы справедливо сказать, что в целом стоит использовать данный шаблон проектирования, если он дает вам больше преимуществ, чем затрат. Каждый шаблон вводит дополнительный уровень косвенности в коде, поэтому ему труднее следовать, особенно для младших членов команды. Сказав это, я думаю, что шаблон Chain of Responsibility определенно полезен, если вы не знаете заранее, какие будут классы, которые будут выполнять обработку (находясь в цепочке), или вы повторно используете эти классы в разных контекстах, создаете разные цепочки в разных сценариях и т. д.

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