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

Question

我想确定，如果（在我开始之前）在一个新项目上，我可以选择一些合适的模式，这将随着项目变得更加复杂而帮助开发。

场景

要具有在屏幕上绘制“简单的”行的应用程序。理想情况下，我可以将其包含到Silverlight，WPF演示应用程序等中的“渲染引擎”中。我还需要使用渲染引擎执行大量显示的编辑器应用程序，但它提供了诸如控制点移动有关屏幕&对话框线用于改变线等

目标的颜色

为了保持渲染引擎specalised和高效。编辑器应该能够将附加功能（即控制点的显示）“注入”渲染引擎使用的对象或渲染引擎本身。我不想将任何编辑器特定的代码编码到渲染引擎中。

我的想法至今

我想使用将由渲染引擎使用对象的封装/模板图案的，在某种程度上允许编辑器应用程序提供类的对象， '控制'控制点的功能（例如移动控制点的事件处理）。

我喜欢这个想法背后的原因是渲染引擎永远不需要知道它的工作环境。编辑器可以被广泛地改变，而不必改变渲染引擎（希望）。

但是....

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

Answer 1

我同意查理，你应该从一个简单的设计原型开始，并根据需要扩展它（这就是我如何从我的map rendering engine开始）。我可以给你几点建议，但：

• 将绘图引擎从代码的其余部分（here's an example how）分开。通过绘制引擎，我的意思是实际在屏幕/位图上绘制某些东西的代码。它应该消耗绘图原语，而不是一些更高级别的实体。通过这种方式，您可以轻松切换绘图引擎（例如：SVG，PDF，GDI，WPF ...）
• 如果要使用编辑器，其中一种有用的模式是State pattern

Answer 2

那么拍摄，这是一个令人印象深刻的预谋。

我的理念一直是，当您需要使用一个时，使用设计模式。否则，你可能会变成architecture astronaut，设计盛大的计划都是徒劳的。在开发之前考虑设计是件好事，但实际上，在编写代码之前，您可能知道多少项目？几乎没有。如果你在编写任何代码之前强迫自己进入模式，那么在应用程序的整个生命周期中，最终可能会将方块插入圆孔中。

我给你的建议：先写一个原型。快速和肮脏。没有真正的设计;只是做一个走路的骨架。从中学习。如果您想到更好的方法，请废弃原件并重新设计一个新的原件。当您添加功能时，请使用有意义的设计模式，而不是为了添加功能。