Я работаю над программным обеспечением, предназначенным для создания книги, подобной документу. Я реализовал это, используя декораторы для добавления различных функций. Вот пример инициализации'
$this->chapter[i] = new ChapDecorator1(new ChapDecorator2(new Chapter(i)));
Проблема заключается в том, что эти декораторы жестко запрограммированы и существует потенциал для многих итераций программного обеспечения. Интересные изменения, сделанные в новых проектах, часто переносятся в более старые (что теперь не так уж и страшно с декораторами, поскольку все, что требуется, это добавить еще один декоратор в определение). Однако это по-прежнему требует от меня редактирования кода подкласса. Оптимальная ситуация, когда фактические создатели контента выбирают, какие функции им нужны, не требуя, чтобы программист что-либо редактировал.
Ясно, что в этом случае лучше, чтобы Книга использовала объект, реализующий шаблон Builder, для создания объекта Chapter и обернула его в правильные декораторы для проекта.
Наконец, мы подошли к моему вопросу: как я могу заставить объект построителя динамически и правильно обрабатывать порядок конфигурации? Порядок, в котором обёрнуты декораторы, подразумевает порядок разрешения интерфейсных вызовов (LIFO). Например, отслеживание редактирования документа реализовано как декоратор, но по понятным причинам всегда следует сначала оценивать состояние сохранения перед внесением изменений (это должна быть последняя оболочка). Для будущего развития, предполагая, что будет много декораторов, некоторые из которых, возможно, должны быть разрешены в первую очередь, если у каждого декоратора есть что-то вроде члена приоритетных данных (целого числа?), Который Builder может сортировать? Это похоже на работоспособное решение, но я обеспокоен тем, что реализация не будет очень надежной, если будет создано большое количество декораторов/модулей, чувствительных к приоритетам. Например, конфликтующие приоритеты могут потребовать перенумерации многих классов. В любом случае, я был бы признателен за любые мысли людей по этому поводу.
Вторая проблема заключается в том, что два декоратора каким-либо образом изменяют одну и ту же функцию. Должна ли вообще быть возможна такая ситуация? Должен ли каждый декоратор указывать свой домен и просматривать список декораторов в поисках конфликтов?
Все это предполагает, что будет много декораторов и что некоторые редакторы проектов выберут одних, но не других. Спасибо!
