软件设计的7大原则

设计软件的几个原则，这个也是设计模式的精髓所在：

 

一、开闭原则(OCP)

开闭原则（Open-Closed Principle）：一个软件实体应当对扩展开放，对修改关闭。

客户的需求是不稳定的，通过扩展已有的软件系统而不是通过修改软件系统来满足客户的需求，这样的软件系统就满足开－闭原则，即软件系统要有一定的灵活性和适应性。

已有的模块，特别是抽象层的模块不能修改，保证软件系统的稳定性和延续性。解决问题的关键是抽象化，把它与具体实现分离开来。接口（interface），抽象类的应用对可变性封装：将可变性封装到一个对象里。优点是通过扩展已有软件系统，可以提供新的行为，以满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。

 

二、里氏代换原则（LSP）

里氏代换原则（Liskov Substitution Principle）：子类型必须能够替换它们的基类型。反过来的代换不成立。

当两个具体类关系违反里氏代换原则时，一种办法是抽象出一个基类，作为这两个类的父类，一种是应用组合聚合关系建立关系。不要为了使用某些类的方法（功能）而滥用继承。

 

三、 依赖倒置原则(DIP)

依赖倒置原则(Dependence Inversion Principle)：具体要依赖于抽象，抽象不要依赖于具体。

简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必再弄一个抽象类做它的父类，这样有画蛇添足的感觉。

 

四、 接口隔离原则（ISP）

接口隔离原则（Interface Segregation Principle）：使用多个专门的接口比使用单一的总接口总要好。

换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。

 

五、 合成/聚合复用原则（CARP）

合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）：就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。

简而言之，要尽量使用合成/聚合，尽量不要使用继承。区分Has a和Is a的问题。

合成：一荣俱荣，一损俱损，整体和部分的生命周期是一样的。

聚合：部分可以是整体的一部分，也可以脱离整体而存在。

 

六、 迪米特法则（LoD）

迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP）：一个对象应当对其它对象有尽可能少的了解。不要和陌生人说话。

 

七、抽象类原则

抽象类不会有实例，一般作为父类为子类继承，一般包含这个系的共同属性和方法。

注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。