可复用设计：组件还是类，这是个问题

当封装一个功能模块时，第一个想法是我可以把它封装成一个类，如果你使用 RAD 的方法，那么要考虑的下一个问题是要不要把它做成一个组件。

看到这里， RAD 的反对者应该准备关闭窗口了，因为他们不考虑“组件”这个词。但不管用不用 RAD 的概念，面临的问题是一样的，只是有不同的解决方法。

一般当一个类要晋级成一个组件时，一个重要的原因就是有 可持久的（ ** persistent ** ** ） ** 配置数据。组件的属性是可在 IDE 里配置并保存的；而在不用 RAD 的模式里，如 Java 常用的发布功能模块的方式里，是用程序外部的配置文件来配置和保存配置数据。比较而言， RAD 方式自动完成了数据配置的琐碎工作，而且这些数据是程序内部的，这对大量应用组件的情况很重要，因为：

1. 绝大部分属性是不希望保露在外部给用户修改的

2. 不希望因为组件多而导致一大对的配置文件

3. 当用了同一个组件的多个副本时，外部配置文件会有重名文件问题

4. 集成多个功能模块时，统一的配置方式比各行其道的配置文件要容易维护管理

当然用外部配置文件也有它的好处，可以让用户不修改程序而调整程序的行为，但 RAD 并不阻止人用外部配置文件。这里也体现了组件模式在模块集成时的优势。

可以考虑使用组件的情况还包括利用 IDE 的能力方便该类的使用。常见的情况如下：

1. 当该模块在集成时要和其他有限几个组件相关联时。具体例子如一个绘制 Office 风格菜单的控件，添加到 Form 后要和菜单组件关联。

2. 当要在编辑器看到效果时，如打印预览组件。

当然，做成组件的首要前提是这个东西具有足够的可复用性，否则也是意义不大。

反过来，不必做成组件的情况要更多一些，因为多数情况下并不需要组件带来的能力，也就没必要付出组件的代价。组件的代价也不大，但如果要创建一个组件的一百万个实例，就需要考虑设计是不是出了什么问题了。