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

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

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

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

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


oop design-patterns chain-of-responsibility
person Elijah    schedule 27.01.2009    source источник

Ответы (2)


arrow_upward
9
arrow_downward

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

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

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

person krosenvold    schedule 27.01.2009

arrow_upward
3
arrow_downward

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

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

person Grzenio    schedule 27.01.2009