模式:渲染引擎允许编辑器集成？

Question

我正试图确定，如果(在我开始之前)在一个新的项目中，我可以选择一些合适的模式，这将有助于开发，因为项目变得更加复杂。

场景

在屏幕上绘制“简单”线条的应用程序。理想情况下，包含在一个‘渲染引擎’，我可以打包到Silverlight，WPF演示应用程序等。

我还需要编辑器应用程序，它使用呈现引擎来完成大部分显示，但是提供了额外的功能，比如用于移动屏幕上的线条的控制点&用于更改线条颜色的对话框等等。

目标

保持渲染引擎的规格和效率。编辑器应该能够向呈现引擎使用的对象或呈现引擎本身“注入”附加功能(即显示控制点)。我不想将任何编辑器特定的代码编码到呈现引擎中。

我的想法到目前为止，

我正在考虑对呈现引擎将要使用的对象使用一个封装/模板模式，以某种方式允许编辑器应用程序向对象提供一个类，该对象可以为控制点的功能“定位”(例如，用于移动控制点的事件处理)。

我喜欢这个想法的原因是渲染引擎不需要知道它工作的环境。编辑器可以进行广泛的更改，而不必更改呈现引擎(希望如此)。

但是.

我可能是错的，如果有人能看到任何陷阱，或有更好的方法来解决这个问题的经验，我很想听到他们！

Answer 1

我同意Charlie的观点，您应该从一个简单的设计原型开始，并根据需要对它进行扩展(这就是我从我的地图绘制引擎开始的方式)。不过，我可以给你一些建议：

• 将绘图引擎与代码的其余部分(下面是一个例子)分开。所谓绘图引擎，我指的是在屏幕/位图上实际绘制一些东西的代码。它应该消耗绘图原语，而不是一些更高级的实体。这样您就可以轻松切换绘图引擎(例如: SVG、PDF、GDI、WPF.)
• 如果您想拥有一个编辑器，其中一个有用的模式是状态模式。

Answer 2

好吧，那是一个令人印象深刻的先见之明。

我的哲学一直是，当您需要使用一个时，使用一个设计模式。否则，你可能会成为一个建筑航天员，设计宏伟的方案都是徒劳的。在开发之前考虑设计是很好的，但实际上，在编写任何代码之前，您可能知道多少关于该项目的信息呢？几乎什么都没有。如果您在编写任何代码之前强制自己进入一个模式，那么在应用程序的整个生命周期中，您可能会将正方形钉塞到圆孔中。

我给你的建议是:先写一个原型。又快又脏。没有真正的设计，只要做一个能行走的骨架。从中吸取教训。如果你想出一个更好的方法，就放弃原来的，重新设计一个新的。在添加功能时使用有意义的设计模式，而不是为了添加功能。