接口和设计原则.doc

11种设计原则 类原则 1.单一职责原则 - Single Responsibility Principle(SRP) 就一个类而言，应该仅有一个引起它变化的原因。 职责即为“变化的原因”。 2.开放-封闭原则 - Open Close Principle(OCP) 软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 ) 3.里氏替换原则 - Liskov Substitution Principle(LSP) 子类型(subclass)必须能够替换掉它们的基类型(superclass)。 4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP) 抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原则: Dont call us, well call you. 程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。 任何方法都不应该覆写他的任何基类中的已经实现了的方法。 5.接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。 包(类库、DLL)内聚原则 6.重用发布等价原则(REP) 重用的粒度就是发布的粒度。 7.共同封闭原则(CCP) 包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包产生影响， 则将对该包中的所有类产生影响， 而对于其他的包不造成任何影响。 8.共同重用原则(CRP) 一个包(类库、DLL)中的所有类应该是共同重用的。 如果重用了包(类库、DLL)中的一个类， 那么就要重用包(类库、DLL)中的所有类。 (相互之间没有紧密联系的类不应该在同一个包(类库、DLL)中。) 包(类库、DLL)耦合原则 9.无环依赖原则(ADP) 在包的依赖关系图中不允许存在环。 10.稳定依赖原则(SDP) 朝着稳定的方向进行依赖。 应该把封装系统高层设计的软件（比如抽象类）放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。 11.稳定抽象原则(SAP) 包的抽象程度应该和其稳定程度一致。一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的. ) 其它扩展原则 12.BBP(Black Box Principle)黑盒原则 多用类的聚合，少用类的继承。 13.DAP(Default Abstraction Principle)缺省抽象原则 在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作. 14.IDP(Interface Design Principle)接口设计原则 规划一个接口而不是实现一个接口。 15.DCSP(Dont Concrete Supperclass Principle) ? 不要构造具体的超类原则，避免维护具体的超类。 16.迪米特法则 ?一个类只依赖其触手可得的类。 Open-Closed Principle 软件设计中的“开-闭原则” 　　这个原则最早是由Bertrand Meyer提出,英文的原文是:Software entities should be open for extension,but closed for modification.意思是说,一个软件实体应当对扩展开放,对修改关闭.也就是说,我们在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,换句话说就是,应当可以在不必修改源代码的情况下改变这个模块的行为. 　　满足OCP的设计给系统带来两个无可比拟的优越性. 　　1.通过扩展已有的软件系统,可以提供新的行为,以满足对软件的新需求,使变化中的软件系统有一定的适应性和灵活性. 　　2.已有的软件模块,特别是最重要的抽象层模块不能再修改,这就使变化中的软件系统有一定的稳定性和延续性 接口隔离原则isp 一个类对另一个类的依赖应该表现成依赖尽可能小的接口。 这个原则是用来处理胖接口的缺陷，避免接口承担太多的责任。比如说一个接口内的方法可以被分成好几组，分别为不同的客户程序服务，说明这个接口太胖了。当然，确实也有一些类不需要内聚的接口，但这些类不应该做为单独的类被客户程序直接看到，而应该通过抽象基类或接口来关联访问。 接口污染 所谓接口污染就是为接口添