灵活性和可扩展性通常成对出现。程序的模型越是抽象，越要求灵活性和可扩展性。客户在需求描述的初始阶段往往对自己的业务模型并不熟悉。客户不是数学家和 计算机专家，他们对自己的需求很难抽象出一个精确的模型来，这使得他们只能给出一个模糊的抽象的业务模型。拙劣的程序员往往将用户给的模糊模型根据自己的 理解后，定义出一个自己认为准确和精确的模型。在软件提交后，用户就会往往发现这不是我所要，或者是我要的，但只是其中情况的一种。于是，这儿添一点功 能，那儿添一点功能。程序设计的时候由于模型抽象层次不高，造成的灵活性和可扩展性比较差，这时程序员的末日来了。
因此一个好的程序员不仅仅是写一段美观高效的代码，更重要是要有出众的设计能力。良好的设计能给实现带来很好的灵活性和可扩展性。高级的程序员首先应该是一个高级的程序设计师，这样的程序员不仅要有良好的需求分析能力，还要有高超的模式设计能力。
在获知抽象的业务模型后，如何设计你的程序，使其具有高度的灵活性和可扩展性是每个程序员应该关心的问题。在Java中，让一个程序具有灵活性和可扩展性的方法不外乎以下几种方式：
1.程序级别的灵活性，主要通过参数化配置程序低级别的灵活性。
2.高度可配置性，包括各种虚拟机参数、属性文件和XML配置文件。
3.脚本。脚本是扩展复杂功能的利器，但对用户的要求也比较高。通常应该面向开发人员的工具产品。或者在产品部署之前由现场实施人员来完成。
4.插件系统或者模块化平台。插件系统平台从理论上提供了无数的可扩展性。比如Eclipse和NetBeans平台。这儿是抽象的最高点，产品可以一无用处，也可以无所不能。完全看市场有什么插件，用户怎么配置。
灵活性和可扩展性固然有好处，但是不应该成为需求采集和分析阶段偷懒的依据。因为灵活性和可扩展性不是都是好的，任何事情都有双面性。灵活性和可扩展性对于开发者来说减小的开发和维护成本，但是如果客户服务做的不好，往往是客户的噩梦。很明显，这些问题包括：
1.易用性。越是灵活，用户的使用难度就越大，如果没有产品的现场实施人员的服务，对于非计算机人专业用户来说，这实际增加了他们使用的难度。 Eclipse的平台正在展现这种问题，虽然它的用户主要是开发者，即时插件文档做得很好，但是很多人不得不抱怨Eclipse需要太多得配置和技巧。另 外典型的例子是Windows和Linux要求有不同能力的人来使用，原因在于，Linux的灵活性和可扩展性也是其易用性差的原因之一。
2.稳定性。越是灵活和可扩展，其稳定性越差。这主要是灵活性带来的现实世界的排列组合太多了，版本之间的兼容性，大范围开发者之间的协作就不可避免的差 了。作为这方面的例子应该说eclips表现的比较明显了。由于版本冲突的问题，造成Eclipse经常因为不正确的配置插件而Crash。
3.性能。微内核/插件模式设计的缺点表现在不同插件之间的交互性能损失上。Unix系统之所以没有采取现代操作系统所提倡的微内核模式，恐怕原因也在于此。
尽管有上面的缺点，现代软件理论还是非常提倡灵活性和可扩展性的。灵活性和可扩展性付出的代价应该在软件服务中得到弥补。灵活性和可扩展性是现代软件工程 着重解决的目标之一，它不仅仅能提高软件的质量，也使得软件开发过程的质量得到提高。尤其是大型的软件，模块化不仅仅是灵活性和可扩展性的基础，也是软件 开发协作的基础。
（常州java培训机构 http://www.thinksite.cn/list-114-1.html）
