软件技术方案设计原则

软件技术方案设计原则

　　软件开发是一项高强度的脑力劳动过程，到目前为止尚没有办法使软件开发完全机械化，只能靠人脑去设计，也无法保证一个软件完全没有错误。同硬件产品相比，一方面是同功能的软件产品不再需要一个生产过程，只需要拷贝就行了，而硬件产品却需要重复生产;另一方面，软件产品功能需求的变化远比硬件产品多。这就造成软件产品和硬件产品在成型之后面临的问题是不同的，软件产品主要是应付用户功能需求的变化和扩展，硬件产品主要着眼于如何大规模地生产。硬件产品的大规模生产可以交给机器去执行，而软件产品的需求变化还是要靠人脑去完成。以下是软件技术方案设计原则，欢迎阅读。

　　如何快速开发出符合用户功能需求的软件，如何保证开发出的软件尽可能少地出现错误，如何使开发出的软件能够容易地适应用户功能需求的变化和扩展，是所有软件开发人员追求的目标;我想，也正是为了实现上述目标，才有了软件设计原则和设计模式。

　　软件开发是起始于面向过程的，为什么会这样呢?我想是因为面向过程地解决问题更直接，软件本身就是一个解决问题的过程;面向过程的最大问题就是不容易把问题进行分解，再大的问题都要在一个过程里面解决，从第一步直到最后一步;最多是把一个大过程分解成几个顺序执行的小过程，很考验人的逻辑推理能力，开发出的软件不容易维护、重用和扩展。面象对象的方法没那么直接，需要有一个抽象的过程，要把问题抽象成一个个对象，每个对象解决一个小问题，不同对象的组合就可解决不同的大问题;而且把对象跟日常的事物联系起来，产生了属性、事件、方法这样的概念，增加了对象的直观性。

　　设计原则和设计模式都是针对面向对象的设计方法而提出来的，如果在软件开发中还完全采用面向过程的方法，是无所谓设计原则和设计模式的。在软件开发中，面向过程是起步，是基础，没什么好研究的了;面向对象才是深入，是王道，需要不断地去总结方法;下面的软件设计都是指面向对象的设计方法。

　　根据前人总结的经验，在软件开发中，遵循一定的设计原则，灵活地采用一些设计模式，可以提高软件的易维护性、可扩展性以及重用的机率。关于这方面最权威的著作恐怕就是Robert C. Martin写的敏捷软件开发一书了;关于这本书，个人阅读的理解如下：

　　一、设计原则，该书提出了如下设计原则：

　　1、单一职责原则(SRP)：一个类只实现一个功能;换一种说法，一个类只能有一个引起它变化的原因;在软件工程中有一个要求，叫做高内聚;一个类只实现一个功能，无凝内聚度是最高的了;这一原则可以使一个类更好地被重用;当然，“一个功能”是相对的，在某种情况下，MODEM功能是一个单一功能，而在另一种情况下，可能就要把MODEM功能再分解成多个小功能;

　　2、开放封闭原则(OCP)：开放是指一个类能够扩展功能，封闭是指这个类对于功能修改是封闭的，也就是说不能修改其已有的代码和功能;要实现这一目标，关键是抽象;在客户类中只使用抽象基类，在应用中子类继承基类，并按实际需要扩展基类的功能;按更通俗的说法就是：接口不能改变，功能可以扩展;

　　3、子类替换原则(LSP)：就是一个子类在任何情况下，都能替换掉它的基类;这是面向对象设计方法中实现继承和多态必须遵循的一条基本原则，显然也是开放封闭原则能够实现的基础;如何实现这一原则呢?那就是子类必须要有比基类相同或更弱的前置条件，相同或更强的后置条件;前置条件就是调用一个方法之前必须满足的条件，后置条件就是一个方法执行之满足的条件;为了更清楚地说明这一个问题，见下面的函数表达式：

　　Y = F(X);

　　F是一个函数，X是一个整型的输入参数，Y是一个整型的返回值，如果F要求X>0，返回值Y>1，则X>0和Y>1就分别是F的前置条件和后置条件;如果F是基类A中的一个函数，B是A的一个子类，并扩展了F的功能，则B类中F的前置条件必须跟A类中的相同或更弱，也就B类中的F必须至少能接受X>0，如果能同时接收X<=0的条件更好，但不能要求X>1，这是一个X>0更强的条件;B类中的F必须保证返回值Y>1，当然如果能保证Y>10更好，但不能使返回值Y<=1，这样就不满足A类中F返回值Y>1的条件;不满足子类替换原则最直接的后果就是使应用程序产生BUG;必须说明的是，在实际中是很难完全遵循子类替换原则的，必须作合理的假设，在这个假设的前提下遵循子类替换原则，这就是所谓契约设计;

　　4、依赖倒置原则(DIP)：就是上层模块不能依赖于下层模块，两者都应该依赖抽象;抽象不能依赖细节，细节应该依赖于抽象;对这一原则要灵活看待，因为这一原则和当前开发中常用组件开发方式看起来是相矛盾的;首先明确定义一下上层模块和下层模块，所谓上层模块是调用别人的模块，也可称之为客户模块，下层模块是被别人调用的模块，也可称之为服务模块;显然这是一个相对的概念，因为一个模块很可能同时即调用别的模块，又被另外的模块调用;依赖倒置原则告诉我们客户模块和服务模块不能互相依赖，而只能依赖于一个抽象的基类;另外这个抽象基类的接口是由客户模块决定，而不是由服务模块决定;也就是说客户模块需要什么，服务模块就提供什么，而不是服务模块提供什么，客户模块就使用什么;这颇有点当前企业信奉的一个原则：客户就是上帝，客户需要什么，我们就提供什么;而我们当前常用的组件编程中，每一个组件都是一个被别人调用的具体类，显然是属于细节和服务模块，我们调用组件，实际上就依赖了这些组件的模块;根据依赖倒置原则是不是就不能调用这些组件呢?当然不能这么呆板，在设计中还有另一条原则，稳定依赖是没有害处的;说到底，这些组件也是根据客户需求制定出来的，只不过是已经固化了的需求;而且这些组件经过了严密测试，是稳定的，依赖它们没有害处;依赖倒置原则是针对我们自己的设计来说的;当然，如果我们自己设计的某一个服务类经过了严格的测试和大量的使用，都已经验证没有问题，也可以作为一个通用的组件，别人可以调用它，依赖它，没有问题;

　　5、接口隔离原则(ISP)：这一原则好象是单一职责原则的升级版，接口隔离原则强调的是当一个服务类需要被即有共同功能需求又有不同功能需求的客户类使用时，不能在服务类中加进它的客户不需要的方法，比如在服务类A的客户中， B类客户需要F方法，而C类客户则不需要F方法，这时不能简单地把F方法加到服务类A中以满足B类客户的需求，而应分离接口;比如另设计一个服务类D，其中包含F方法，并把共用的功能委托给A实现，这样B客户可以使用D，而C客户继续使用A;对这一原则我有所保留的是：如果F方法对C类没有影响，直接加到A类中也无防，而且这种情况是很普遍;

　　6、共同封闭原则：这是针对包的;一个包对应用一个程序文件，包含一到多个类，这些类具有共同的封闭性，要么是都不能修改，要么是只能由同一原因引起修改;

　　7、共同重用原则：也是针对包的;不同类的通用性也是不一样的，通用性最高的就是在所有项目中都可使用，比如我们用到的集成开发工具中的组件;有些类可能包含些行业特征，只能这一行业类的软件中使用，有些类包含了某一个项目的特征，就可能在该项目中使用;但是一个包中的所有类的通用性都应该是一样的，这样才能保证包的重用度最大化;

　　二、设计模式，该书列出了以下常用的设计模式;

　　1、策略模式(STRATEGY)：在一个拥有通用算法的具体类中，把一些调用的方法委托给一个接口类实现，通过接口的不同实现，扩展不同的功能;策略模式能够重用通用具体类，又易于扩展功能;

　　2、工厂模式(FACTORY)：在一个工厂类中，传入不同的参数，可生成不同的类(相同的接口，不同的实现);工厂模式易于扩展功能;

　　3、封装模式(FAADE)：对一个具有复杂接口的类(或API函数)进行封装，并提供几个简单的接口供外部调用;封装模式可以隔离复杂的接口，并使其使用变得简单;

　　4、命令模式(COMMAND)：上层模块要操作一组COMMAND对象，这些COMMAND对象都具有同样的方法(不同的实现)，上层模块在操作COMMAND对象时，只需要调用它们的方法，而不用关心方法的实现;在某些情况下，这种模式会极大地简化系统;

　　5、组合模式(COMPOSITE)：当A调用B，一对一的关系，需要改变为A调用多个B(或B的子类对象)时，不更改A的代码(比如在A中创建一个B或B的子类对象的列表，再依次从列表中取出对象调用)，而是从B继续一个子类C，在C类中创建B或B的子类对象的列表，重写C类中相应的方法为依次调用列表中对象的方法，从而用A和C一对一的关系代替A和B之间一对多的关系，并保持A的代码不用更改;

　　6、观察者模式(OBSERVER)：在被观察者中提供注册接口(Register)用于注册观察者，所有注册的观察者都放入一个列表中，在观察者中提供观察接口(Update)，用于接收被观察者发出的通知;当被观察者发生变化时，依次调用列表中的观察者的观察接口(Update)，观察者在观察接口(Update)中，对感兴趣的被观察者变化进行处理;

　　7、代理模式(PROXY)：主要用于代理数据库操作，可以实现数据库操作和业务操作的代码分离;实现模式如下：

　　应用程序调用一个接口A，B和C都实现A中的所有接口，其中B是知晓数据库的代现，利用一个数据库类D进行数据库操作，然后委托相应的方法给C;代理模式使用不多，主要是在B类中把方法再委托给C，在大多数情况下都没有必要;

　　8、适配器模式(ADAPTER)：在一个稳定的架构中，增加一个外部组件，但该组件的接口不符合架构的规范，这时就可创建一个适配器类对外部组件进行封装，适配器的接口符合架构的规范(这样才能纳入架构)，相应的方法委托给外部组件实现;这样就可把外部组件纳入到已有的架构中;另外，也可能是需要提供一个具有不同接口的组件给另外的客户端使用，同时又要把该组合件的功能纳入到已有的架构中，通过一个适配器把组件纳入架构，另外的客户端直接使用组件;

　　最后说明：使用设计模式是有代价的，可能需要增加新的类，编写额外的代码，增加复杂度;优势就是，可以使系统更适应于功能需求的变化，包括功能修改和扩展，隔离变化等;可以提高代码的重用率;所以对于设计模式，不能生搬硬套，而应是顺势而为。

【软件技术方案设计原则】相关文章：

技术方案设计原则04-25

软件技术专业自我评价07-05

选股票的原则07-04

MBA的面试原则07-01

股票成交原则07-02

股票的成交原则07-02

春分养生原则07-12

立冬养生原则07-05

面试的原则解析07-13

坚持HR的原则07-09