可复用设计：组件还是类，这是个问题
当封装一个功能模块时，第一个想法是我可以把它封装成一个类，如果你使用RAD的方法，那么要考虑的下一个问题是要不要把它做成一个组件。
看到这里，RAD的反对者应该准备关闭窗口了，因为他们不考虑“组件”这个词。但不管用不用RAD的概念，面临的问题是一样的，只是有不同的解决方法。
一般当一个类要晋级成一个组件时，一个重要的原因就是有可持久的（persistent）配置数据。组件的属性是可在IDE里配置并保存的；而在不用RAD的模式里，如Java常用的发布功能模块的方式里，是用程序外部的配置文件来配置和保存配置数据。比较而言，RAD方式自动完成了数据配置的琐碎工作，而且这些数据是程序内部的，这对大量应用组件的情况很重要，因为：
1. 绝大部分属性是不希望保露在外部给用户修改的
2. 不希望因为组件多而导致一大对的配置文件
3. 当用了同一个组件的多个副本时，外部配置文件会有重名文件问题
4. 集成多个功能模块时，统一的配置方式比各行其道的配置文件要容易维护管理
当然用外部配置文件也有它的好处，可以让用户不修改程序而调整程序的行为，但RAD并不阻止人用外部配置文件。这里也体现了组件模式在模块集成时的优势。
可以考虑使用组件的情况还包括利用IDE的能力方便该类的使用。常见的情况如下：
1. 当该模块在集成时要和其他有限几个组件相关联时。具体例子如一个绘制Office风格菜单的控件，添加到Form后要和菜单组件关联。
2. 当要在编辑器看到效果时，如打印预览组件。
当然，做成组件的首要前提是这个东西具有足够的可复用性，否则也是意义不大。
反过来，不必做成组件的情况要更多一些，因为多数情况下并不需要组件带来的能力，也就没必要付出组件的代价。组件的代价也不大，但如果要创建一个组件的一百万个实例，就需要考虑设计是不是出了什么问题了。
