关于软件设计的几点思考

关于软件设计的几点思考

平时我们常讲“软件设计”，这个词好像成了一个习惯用语。但是什么是软件设计，这样一个本质问题，要说出所以然来还真的是有点不容易。就好比这样一个问题：软件开发者就是工程师吗？如果没有弄清什么是软件设计，回答起来同样令人头痛。

但是在这篇文章中我并不计划就“什么是软件设计”这一问题作深入的讨论，我打算在下文中介绍以下三个方面的内容：1、什么是软件设计？2、软件危机与软件质量。3、面向对象软件设计原则。

一、什么是软件设计？

关于“什么是软件设计”这样一个问题，Jack W.Reeves 于14年前（1992年），就在其撰写的论文——《What is Software Design》中给出了其个人观点——“源代码就是设计”。这一思想将软件工程活动与传统的工程活动区分开来，传统的工程活动中设计过程中产生的仅仅只是设计文档，构建过程完全依赖于设计文档；而软件的设计活动将源代码的编写也包含了进来，其不仅仅只是生产文档。

这一理论听起来似乎有些抽象，不妨来个类比：建筑设计行业中，建筑设计图的最终完成标识了设计过程的终结，但是软件设计过程能够用软件设计文档的完成作为其结束标识吗？显然这是一个不可能的答案。软件设计的复杂性与不确定性我想大家都深有体会，很多时候文档与代码之间的修改是一个反复的过程。因为需求分析阶段中我们不可能全部得到客户心里真正想要的是什么东西。即使知道客户想要的是什么，同时也得随时准备应付客户不断变化的新的要求。这是一场残酷的战争，战争没有结束的时候谁也不能确信他就是真正的赢者。

这一理论回答了“软件开发者就是工程师吗？”这一问题，揭示了编程与程序之间的关系：编程不是构建软件，而是软件设计。它将编码这一阶段包含在软件设计过程中，同时又强调了顶层设计的重要性。

从这一理论出发，去思考软件开发的几个模型，我们会很清晰地理解以文档驱动为核心的瀑布模型在当今开发过程中存在的先天不足和后天失调，它体现出来的优点就是严格控制的自顶向下的流程化工程思想。再看以面向对象为指导思想的喷泉模型，它强调的是无间隙、迭代化开发，其重点不再是设计文档，而是如何面对复杂可变的现实环境。软件设计是一个反复的迭代的过程，就目前来讲还看不到“银弹”的希望。

二、软件危机与软件质量：

 “软件危机”的提出使得人们开始对软件及其特性进行更深一步研究，概括地来讲就是解决这两个方面的内容：如何开发软件，怎样满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。

面对“软件危机”，与程序设计方法学密切相关的软件工程在1968年应运而生。软件工程研究的内容主要包括：软件质量保证和质量评价；软件研制和维护的方法、工具、文档；用户界面的设计以及软件管理等。就如何保证软件质量问题，各国软件界都给予了广泛关注与研究。国际标准化组织于2001年重新制定的ISO/IEC 9126标准，为保证软件质量、评估软件质量提供了依据。

ISO/IEC 9126软件质量模型分为三层：特性、子特性和度量。软件质量是特性的函数，每一特性又由一些子特性来衡量，而每一子特性又由一些定量化指标的度量来描述。按照影响软件质量的各特性之间覆盖最小的原则，可以将软件质量分为六个特性：功能性、可靠性、易用性、效率、可维护性和可移植性。

三、面向对象软件设计原则：

软件设计的目标就是如何实现及保证软件质量，我们评估软件设计的好坏也就是通过软件质量的六个特性作为依据。为了顺利实现及保证软件质量，业界经过几十年的发展与积累，逐渐形成了开发过程中应遵从的原则。下面是面向对象软件设计过程中最常用的5个原则：

A．单一职责原则（SRP）：

一个类应该有且只有一个改变的理由。也就是解决职责不清的问题，通俗地讲，既当爹又当妈这种行为用在软件设计中是不可取的。采用这一原则进行设计的最大好处是提高软件的可靠性与可维护性。

B．开放—封闭原则（OCP）：

在不用修改原有类的基础上就能扩展一个类的行为。如何正确理解“开放与封闭”，其对谁“开放”对谁“封闭”？这是我们理解这一原则的最大困难之处。它强调的重点在于“对于扩展它是开放的，对于修改它是封闭的”，其实也就是隔离变化，既达到职责单一又达到了扩展的目的。

C．替换原则（LSP）：

派生类要与其基类自相容。也就是说“子类型必须能够替换掉它们的基类型”。这一原则其实是对OCP原则的扩展，它强调的重点其实就是“父为子纲”。没有父亲也就没儿子，这种继承关系始终如一，不得改变。这一常理在这一原则中倒是得到了很好的体现。

D．依赖倒置原则（DIP）：

依赖于抽象而不是实现。还有一种说法：抽象不应该依赖于细节，细节应该依赖于抽象。就我个人的观点来讲，我不喜欢后面这种说法。它不简洁也容易让人误解。谁的抽象谁的细节？顺藤摸瓜，瓜是抽象，藤是细节。其实这里面包含了归纳的思想，那就是从细节上抽象出其本质的东西。我们依赖的就是这个抽象本质，而不是它的具体实现细节。这又回到我上一原则所讲的“父为子纲”。

E．接口隔离原则（ISP）：

客户只要关注它们所需的接口。说得明白一点就是，“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构”。如果我们把接口理解成角色，一个接口只是代表一个角色，每个角色都有它特定的一个接口，每个角色都服务于其客户端对象。那么用“投其所好”这个成语来形容这一原则，我觉得再恰当不过。虽然其意含贬义，但是它定制化服务、个性化服务则值得我们学习。这一原则强调了对软件实体通信之间的限制，它限制了通信的宽度，同时提供了一个指导化的设计思想，就是说通信要尽可能的窄，只投其所好。遵从这一原则带给我们的好处是：在软件系统功能需要扩展时，其修改的压力会最小。

总之，关于软件设计这样一个课题，要思考与研究的东西实在很多，不只是哪一个人的事情。本文的主旨意在与大家交流自己在工作当中的所想所得，所悟到的东西与事实的本质或许有较大出入，但是我已敞开胸襟，愿意接纳各位同仁的指正与批评。

（注：版权归个人所有，如需转载请注明出处。）