如何为可配置软件设置构建器和装饰器模式？
我正在开发一款软件，旨在创建类似书籍的文档。我已经使用装饰器来添加各种功能来实现它。这是初始化的一个示例。
$this->chapter[i] = new ChapDecorator1(new ChapDecorator2(new Chapter(i)));
挑战在于这些装饰器是硬编码的，并且软件有可能进行多次迭代。对新项目所做的有趣更改通常会向后移植到旧项目（现在对于装饰器来说这并不可怕，因为所需要做的就是向定义中添加另一个装饰器）。然而，这仍然需要我编辑子类代码。最佳情况是实际内容创建者选择他们需要的功能，而不需要程序员编辑任何内容。
显然，在这种情况下，更好的做法是让 Book 使用实现 Builder 模式的对象来创建 Chapter 对象，并将其包装在项目的正确装饰器中。
最后，我们到达我的问题，即如何使构建器对象动态且正确地处理配置顺序？装饰器的包装顺序意味着接口调用的解析顺序（后进先出）。一个例子是文档编辑跟踪是作为装饰器实现的，但出于明显的原因，应该始终在进行更改之前首先评估以保存状态（它应该是最后一个包装器）。对于未来的开发，假设会有很多装饰器，如果每个装饰器都有诸如优先级数据成员（整数？）之类的东西，构建器可能会对其进行排序，那么有些装饰器可能需要首先解决？这似乎是一个可行的解决方案，但我担心如果创建大量优先级敏感的装饰器/模块，实现不会非常稳健。例如，冲突的优先级可能需要对许多类进行重新编号。不管怎样，我很感激人们对此事的任何想法。
第二个问题是两个装饰器是否以某种方式更改相同的功能。这种情况有可能吗？每个装饰器是否应该指定其域并遍历装饰器列表以查找冲突？
这一切都假设有很多装饰器，并且一些项目编辑器会选择一些装饰器，但不会选择其他装饰器。 谢谢！
I am working on a piece of software designed to create a book like document. I have implemented it using using decorators to add various features. Here is an example of the initialization'
$this->chapter[i] = new ChapDecorator1(new ChapDecorator2(new Chapter(i)));
The challenge is that these decorators are hard coded and that there is the potential for many iterations of the sofware. Interesting changes made on new projects are often backported to the older ones (which isn't terrible now with decorators since all that is required is adding another decorator to the definition). However, this still requires me to edit the subclass code. The optimal situation being the actual content creators choosing what features they need without requiring a programmer to edit anything.
Clearly, the better thing to do in this case is for the Book to use an object implementing the Builder pattern to create the Chapter object and wrap it in the correct decorators for the project.
Finally, we arrive at my question which is how can I make the builder object handle the configuration order dynamically and correctly? The order in which decorators are wrapped with imply an order for how interface calls are resolved (LIFO). An example is that the document edit tracking is implemented as a decorator but for obvious reasons should always evaluate first to save state before changes are made (it should be the last wrapper). For future development assuming there will be many decorators, some which might need to resolve first should each decorator have something like a priority data member (integer?) which the Builder might sort on? It seems like a workable solution but I'm concerned that the implementation wouldn't be very robust if a large number of priority sensitive decorators/modules were created. Conflicting priorities might require renumbering many classes for example. Anyway, I would appreciate any thoughts people had on the matter.
The second issue is if two decorators change the same feature in some way. Should that situation even be possible? Should each decorator specify its domain and traverse the list of decorators looking for conflicts?
This is all assuming there will be many decorators and that some project editors will choose some but not others.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为此，您可以使用修改后的构建器，其中为每次调用构建器方法返回不同的构建器类，并且返回的构建器类仅具有构建整个类的所有方法的子集。
这可以让您避免多次调用相同的方法，并且还可以让您控制整体构建顺序。
可以在此处找到示例。
You can use a modified builder for this, where you return a different builder class for each invocation of a builder method, and that returned builder class only has a subset of all the methods to build the overall class.
This allows you to avoid having the same method called multiple times, and also allows you to control the overall build order.
An example of this can be found here.