《接口与接口设计原则》由会员分享，可在线阅读，更多相关《接口与接口设计原则（48页珍藏版）》请在金锄头文库上搜索。
1、word接口与接口设计原如此一11种设计原如此1.单一职责原如此 - Single Responsibility Principle(SRP) 就一个类而言，应该仅有一个引起它变化的原因。 职责即为“变化的原因。 2.开放-封闭原如此 - Open Close Principle(OCP) 软件实体类、模块、函数等应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用局部和实现细节局部清晰的别离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些局部作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 ) 3.里氏替换原如此 - Liskov Substit
2、ution Principle(LSP) 子类型(subclass)必须能够替换掉它们的基类型(superclass)。 4.依赖倒置原如此(IoCP) 或 依赖注入原如此 - Dependence Inversion Principle(DIP) 抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原如此: Dont call us, well call you. 程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。 任何方法都不应该覆写他的任何基类中的已经实现了的方法。5.接口隔离原如此(I
3、SP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。 6.重用发布等价原如此(REP) 重用的粒度就是发布的粒度。 7.共同封闭原如此(CCP) 包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化假设对一个包产生影响， 如此将对该包中的所有类产生影响， 而对于其他的包不造成任何影响。 8.共同重用原如此(CRP) 一个包(类库、DLL)中的所有类应该是共同重用的。 如果重用了包(类库、DLL)中的一个类， 那么就要重用包(类库、DLL)中的所有类。 (相互之间没有严密联系的类不应该在同一个包(类库
4、、DLL)中。) 包(类库、DLL)耦合原如此 9.无环依赖原如此(ADP) 在包的依赖关系图中不允许存在环。 10.稳定依赖原如此(SDP) 朝着稳定的方向进展依赖。 应该把封装系统高层设计的软件比如抽象类放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件比如具体类。11.稳定抽象原如此(SAP) 包的抽象程度应该和其稳定程度一致。一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的. 其它扩展原如此12.BBP(Black Box Principle)黑盒原如此多用类的聚合，少用类的继承。 13.DAP(Default Abstraction Principle)缺省抽象原如此
5、 在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大局部操作. 14.IDP(Interface Design Principle)接口设计原如此 规划一个接口而不是实现一个接口。 15.DCSP(Dont Concrete Supperclass Principle)不要构造具体的超类原如此，防止维护具体的超类。 16.迪米特法如此 一个类只依赖其触手可得的类。 二类的设计原如此接口定义接口定义1.开闭原如此Software entities (classes, modules, function, etc.) should be open for extension, but c
6、losed for modification.软件实体模块，类，方法等应该对扩展开放，对修改关闭。 开闭原如此OCP：Open-Closed Principle是指在进展面向对象设计OOD：Object Oriented Design中，设计类或其他程序单位时，应该遵循： - 对扩展开放open - 对修改关闭closed的设计原如此。 开闭原如此是判断面向对象设计是否正确的最根本的原理之一。 根据开闭原如此，在设计一个软件系统模块类，方法的时候，应该可以在不修改原有的模块修改关闭的根底上，能扩展其功能扩展开放。- 扩展开放：某模块的功能是可扩展的，如此该模块是扩展开放的。软件系统的功能上的可
7、扩展性要求模块是扩展开放的。- 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，如此该模块修改关闭的。软件系统的功能上的稳定性，持续性要修改关闭的。这也是系统设计需要遵循开闭原如此的原因：1稳定性。开闭原如此要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。2扩展性。开闭原如此要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。遵循开闭原如此的系统设计，可以让软件系统可复用，并且易于维护。开闭原如此的实现方法为了满足开闭原如此的 对修改关闭closed for modification 原如此以与扩展开放open for extensio
8、n 原如此，应该对软件系统中的不变的局部加以抽象，在面向对象的设计中，- 可以把这些不变的局部加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；- 接口的最小功能设计原如此。根据这个原如此，原有的接口要么可以应对未来的扩展；不足的局部可以通过定义新的接口来实现；- 模块之间的调用通过抽象接口进展，这样即使实现层发生变化，也无需修改调用方的代码。接口可以被复用，但接口的实现却不一定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。可以通过对接口的不同实现以与类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔软扩展。简单地说，软件系统是否有良好的接口抽象设计是判断
9、软件系统是否满足开闭原如此的一种重要的判断基准。现在多把开闭原如此等同于面向接口的软件设计。开闭原如此的相对性软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块间的关系，都不会从一开始就非常清晰明了，所以构建100%满足开闭原如此的软件系统是相当困难的，这就是开闭原如此的相对性。但在设计过程中，通过对模块功能的抽象接口定义，模块之间的关系的抽象通过接口调用，抽象与实现的别离面向接口的程序设计等，可以尽量接近满足开闭原如此。2.单一职责原如此前言Robert C. Martin氏为我们总结了在面向对象的设计OOD中应该遵循的原如此，这些原如此被称为“Principl
10、es of OOD，关于“Principles of OOD的相关文章可以从Object Menter得到。本文介绍“Principles of OOD中的单一职责原如此：Single Responsibility Principle (SRP)。可以从这里查看Single Responsibility Principle (SRP)的原文。概要There should never be more than one reason for a class to change.永远不要让一个类存在多个改变的理由。换句话说，如果一个类需要改变，改变它的理由永远只有一个。如果存在多个改变它的理由，就需
11、要重新设计该类。SRPSingle Responsibility Principle原如此的核心含意是：只能让一个类有且仅有一个职责。这也是单一职责原如此的命名含义。为什么一个类不能有多于一个以上的职责呢？如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者不同用户：1，一方面，如果一个职责使用了外部类库，如此使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。2，另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。这违反了设计的开闭原如此，也不是我们所期望的。职责的划分既然
12、一个类不能有多个职责，那么怎么划分职责呢？Robert.C Martin给出了一个著名的定义：所谓一个类的一个职责是指引起该类变化的一个原因。If you can think of more than one motive for changing a class, then that class has more than one responsibility.如果你能想到一个类存在多个使其改变的原因，那么这个类就存在多个职责。Single Responsibility Principle (SRP)的原文里举了一个Modem的例子来说明怎么样进展职责的划分，这里我们也沿用这个例子来说明一下
13、：SRP违反例：public interface Modem public void dial(String pno);/拨号public void hangup();/挂断public void send(char c);/发送数据public char recv();/接收数据咋一看，这是一个没有任何问题的接口设计。但事实上，这个接口包含了2个职责：第一个是连接收理dial, hangup；另一个是数据通信send, recv。很多情况下，这2个职责没有任何共通的局部，它们因为不同的理由而改变，被不同局部的程序调用。所以它违反了SRP原如此。下面的类图将它的2个不同职责分成2个不同的接口，
14、这样至少可以让客户端应用程序使用具有单一职责的接口：接口定义具体类实现让ModemImplementation实现这两个接口。我们注意到，ModemImplementation又组合了2个职责，这不是我们希望的，但有时这又是必须的。通常由于某些原因，迫使我们不得不绑定多个职责到一个类中，但我们至少可以通过接口的分割来别离应用程序关心的概念。事实上，这个例子一个更好的设计应该是这样的，如图：具体类实现接口定义小结Single Responsibility Principle (SRP)从职责改变理由的侧面上为我们对类接口的抽象的颗粒度建立了判断基准：在为系统设计类接口的时候应该保证它们的单一职责
15、性。3接口分隔原如此前言Robert C. Martin氏为我们总结了在面向对象的设计OOD中应该遵循的原如此，这些原如此被称为“Principles of OOD，关于“Principles of OOD的相关文章可以从Object Menter得到。本文介绍“Principles of OOD中的接口分隔原如此：Interface Segregation Principle (ISP)。可以从这里查看Interface Segregation Principle (ISP)的原文。概要Clients should not be forced to depend upon interfaces that they do not use.不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。它包含了2层意思：- 接口的设计原如此：接口的设计应该遵循最小接口原如此，不要把用户不使用的方法塞进同一个接口
