返回首页

灵活性与可扩展性

时间:2009-02-05 22:03来源:sina 作者:WilliamChen 点击:
   灵活性和可扩展性通常成对出现。程序的模型越是抽象,越要求灵活性和可扩展性。客户在需求描述的初始阶段往往对自己的业务模型并不熟悉。客户不是数学家和 计算机专家,他们对自己的需求很难抽象出一个精确的模型来,这使得他们只能给出一个模糊的抽象的业务模
  

   灵活性和可扩展性通常成对出现。程序的模型越是抽象,越要求灵活性和可扩展性。客户在需求描述的初始阶段往往对自己的业务模型并不熟悉。客户不是数学家和 计算机专家,他们对自己的需求很难抽象出一个精确的模型来,这使得他们只能给出一个模糊的抽象的业务模型。拙劣的程序员往往将用户给的模糊模型根据自己的 理解后,定义出一个自己认为准确和精确的模型。在软件提交后,用户就会往往发现这不是我所要,或者是我要的,但只是其中情况的一种。于是,这儿添一点功 能,那儿添一点功能。程序设计的时候由于模型抽象层次不高,造成的灵活性和可扩展性比较差,这时程序员的末日来了。

    因此一个好的程序员不仅仅是写一段美观高效的代码,更重要是要有出众的设计能力。良好的设计能给实现带来很好的灵活性和可扩展性。高级的程序员首先应该是一个高级的程序设计师,这样的程序员不仅要有良好的需求分析能力,还要有高超的模式设计能力。

    在获知抽象的业务模型后,如何设计你的程序,使其具有高度的灵活性和可扩展性是每个程序员应该关心的问题。在Java中,让一个程序具有灵活性和可扩展性的方法不外乎以下几种方式:

1.程序级别的灵活性,主要通过参数化配置程序低级别的灵活性。

2.高度可配置性,包括各种虚拟机参数、属性文件和XML配置文件。

3.脚本。脚本是扩展复杂功能的利器,但对用户的要求也比较高。通常应该面向开发人员的工具产品。或者在产品部署之前由现场实施人员来完成。

4.插件系统或者模块化平台。插件系统平台从理论上提供了无数的可扩展性。比如Eclipse和NetBeans平台。这儿是抽象的最高点,产品可以一无用处,也可以无所不能。完全看市场有什么插件,用户怎么配置。

    灵活性和可扩展性固然有好处,但是不应该成为需求采集和分析阶段偷懒的依据。因为灵活性和可扩展性不是都是好的,任何事情都有双面性。灵活性和可扩展性对于开发者来说减小的开发和维护成本,但是如果客户服务做的不好,往往是客户的噩梦。很明显,这些问题包括:

1.易用性。越是灵活,用户的使用难度就越大,如果没有产品的现场实施人员的服务,对于非计算机人专业用户来说,这实际增加了他们使用的难度。 Eclipse的平台正在展现这种问题,虽然它的用户主要是开发者,即时插件文档做得很好,但是很多人不得不抱怨Eclipse需要太多得配置和技巧。另 外典型的例子是Windows和Linux要求有不同能力的人来使用,原因在于,Linux的灵活性和可扩展性也是其易用性差的原因之一。

2.稳定性。越是灵活和可扩展,其稳定性越差。这主要是灵活性带来的现实世界的排列组合太多了,版本之间的兼容性,大范围开发者之间的协作就不可避免的差 了。作为这方面的例子应该说eclips表现的比较明显了。由于版本冲突的问题,造成Eclipse经常因为不正确的配置插件而Crash。

3.性能。微内核/插件模式设计的缺点表现在不同插件之间的交互性能损失上。Unix系统之所以没有采取现代操作系统所提倡的微内核模式,恐怕原因也在于此。

    尽管有上面的缺点,现代软件理论还是非常提倡灵活性和可扩展性的。灵活性和可扩展性付出的代价应该在软件服务中得到弥补。灵活性和可扩展性是现代软件工程 着重解决的目标之一,它不仅仅能提高软件的质量,也使得软件开发过程的质量得到提高。尤其是大型的软件,模块化不仅仅是灵活性和可扩展性的基础,也是软件 开发协作的基础。

顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
发布者资料
小朱 查看详细资料 发送留言 加为好友 用户等级:超级会员 注册时间:2008-11-18 17:11 最后登录:2012-09-01 20:09
推荐内容
热点内容