接口与设计原则

11种设计原则 类原则 1. 单一职责原则-Single Responsibility Principle(SRP) 就一个类而言，应该仅有一个引起它变化的原因。职责即为“变化的原因”。 2. 开放•封闭原则・ Open Close Principle(OCP) 软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的.关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开 来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要) 3•里氏替换原则・ Liskov Substitution Principle(LSP) 子类型(subclass)必须能够替换掉它们的基类型(superclass) o 4. 依赖倒置原则(loCP)或 依赖注入原则・Dependence Inversion Principle(DIP) 抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原则:"Don't call us, we'll call you".程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。 任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。任何方法都不应该覆写他的任何基类中的已经实现了的方法。 5. 接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。 包…内聚原则 6. 重用发布等价原则（REP） 重用的粒度就是发布的粒度。 一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。 7. 共同封闭原则（CCP） 包（类库、DLL）中的所有类对于同一类性质的变化应该是共同封闭的。 8. 共同重用原则（CRP） 一个包（类库、DLL）中的所有类应该是共同重用的。 如果重用了包（类库、DLL）中的■个类， 那么就要重用包（类库、DLL）中的所有类。 （相互之间没有紧密联系的类不应该在同一个包（类库、DLL）中。） 包（类库DLL耦合原则 9. 无环依赖原M（ADP） 在包的依赖关系图中不允许存在环。 10. 稳定依赖原则（SDP） 朝着稳定的方向进行依赖。 应该把封装系统高层设计的软件(比如抽象类)放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件(比如具体类)。 11. 稳定抽象原则(SAP) 包的抽象程度应该和其稳定程度一致。一个稳定的包应该也是抽象的，-个不稳定的包应该是抽象的.) 其它扩展原则 12. BBP(Black Box Principle)黑盒原则 多用类的聚合，少用类的继承。 13. DAP(Default Abstraction Principle)缺省抽象原则 在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作. 14.IDP(lnterface Design Principle)接口设计原则 规划一个接口而不是实现一个接口。 15.DCSP(Don*t Concrete Supperclass Principle) 不要构造具体的超类原则，避免维护具体的超类。 16 .迪米特法则 一个类只依赖其触手可得的类。 Open-Closed Principle软件设计中的"开-闭原则” 这个原则最早是由Bertrand Meyer提出，英文的原文是:Software entities should be open for extension,but closed for modification.意思是说,一个软件实体应当对扩展开 放，对修改关闭.也就是说,我们在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展,换句话说就是，应当可以在不必修改源代码的情况下改变这个模块的行为. 满足OCP的设计给系统带来两个无可比拟的优越性. 1. 通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求,使变化中的软件系统有一足的适应性和灵活性. 2. 已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性 接口隔离原则isp 一个类对另一个类的依赖应该表现成依赖尽可能小的接口。 这个原则是用来处理胖接口的缺陷，避免接口承担太多的责任。比如说一个接口内的方法可以被分成好几组，分别为不同的客户程序服务，说明这个接口太胖了。当然，确实也有 一些类不需要内聚的接口，但这些类不应该做为单独的类被客户程序直接看到，而应该通过抽象基类或接口来关联访问。 接口污染 所谓接口污染就是为接口添加了不必要的职责。在接口中加-个新方法只是为了给实现类带来好处，以减少类的数目。持续这样做，接口就被不断污染，变胖。实际上，类的数目 根本不是什么问题，接口污染会带来维护和重用方面的问题。最常见的问题是我们为了重用被污染的接口，被迫实现并维护不必要的方法。 分离客户程序就是分离接口。如果客户程序是分离的，那么相应的接口也应该是分离的，因为客户程序对它们使用的接口有反作用力。通常接口发生了变化，我们就要考虑所有使 用接口的客户程序该如何变化以适应接口的变化。如果客户程序发生了变化呢？这时也要考虑接口是否需要发生变化，这就是反作用力。有时业务规则的变化不是那么直接的，而 是通过客户程序的变化引发的，这时我们就需要改变接口以满足客户程序的需要。 分离接口的方式•般分为两种，委托和多继承。前'者把请求委托给别的接口的实现类来完成需要的职责，后者则是通过实现多个接口来完成需要的职责。两种方式各有优缺点，通 常我们应该先考虑后一个方案，如果涉及到类型转换时则选择前一个方案。 胖接口会导致客户程序之间产生不必要的耦合关系，牵一发而动全身。分解胖接口，使客户程序只依赖它需要的方法，从设计上讲，简单易维护，重用度也高。 写出漂亮代码的七种方法 首先我想说明我本文阐述的是纯粹从美学的角度来写出代码，而非技术、逻辑等。以下为写出漂亮代码的七种方法: 1,尽快结束if语句 例如下面这个JavaScript语句，看起来就很恐怖： 1 function findShape(flags, point, attribute, list) ( 2 if(!findShapePoints(flags, point, attribute)) ( 3 if(!doFindShapePoints(flags, point, attribute)) ( 4 if(!findlnShape(flags, point, attribute)) ( 5 if(!findFromGuide(flags,point) ( 6 if(list.count() > 0 && flags == 1) ( 7 doSomething(); 8 } 9 ) 10 ) 11 } 12 } 13) 但如果这么写就好看得多： 1 function findShape(flags, point, attribute, list) ( 2 if(findShapePoints(flags, point, attribute)) ( 3 return; 4 } 5 6 if(doFindShapePoints(flags, point, attribute)) ( 7 return; 8 ) 9 10 if(findlnShape(flags, point, attribute)) { 11 return; 12 } 13 14 if(findFromGuide(flags,point) ( 15 return; 16 } 17 18 if (!(list.count() > 0 && flags == 1)) ( 19 return; 20 ) 21 22 doSomething(); 23 24) 你可能会很不喜欢第二种的表述方式，但反映出了迅速返回if值的思想，也可以理解为：避免不必要的else陈述。 2,如果只是简单的布尔运算（逻辑运算），不要使用if语句 例如: 1 function isStringEmpty(str)( 2 if(str === ””){ 3 return true; 4 ) 5 else ( 6 return false; 7 } 8) 可以写为： 1 function isStringEmpty(str)( 2 return (str === 3} 3, 使用空白，这是免费的 例如： 1 function getSomeAngle() ( 2 // Some code here then 3 radAnglel = Math.atan(slope(center, pointl)); 4 radAngle2 = Math.atan(slope(center, point2)); 5 firstAngle = getStartAngle(radAngle1, pointl, center); 6 secondAngle = getStartAngle(radAngle2, point2, center); 7 radAnglel = degreesToRadians(firstAngle); 8 radAngle2 = degreesToRadians(secondAngle); 9 baseRadius = distance(point, center); 10 radius = baseRadius + (lines * y); 11 p1 ["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]); 12 p1["y"] = roundValue(radius * Math.sin(radAnglel) + center["y"]); 13 pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]); 14 pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["yn); 15 // Now some more code 16) 很多开发者不愿意使用空白，就好像这要收费一样。我在此并非刻意地添加空白，粗鲁地打断代码的连贯性。在实际编写代码的过程中，会很容易地发现在什么地方加入空白，这 不但美观而且让读者易懂，如下： 1 function getSomeAngle() ( 2 // Some code here then 3 radAnglel = Math.atan(slope(center, pointl)); 4 radAngle2 = Math.atan(slope(center, point2)); 5 6 firstAngle = getStartAngle(radAngle1, pointl, center); 7 secondAngle = getStartAngle(radAngle2, point2, center); 8 9 radAnglel = degreesToRadians(firstAngle); 10 radAngle2 = degreesToRadians(secondAngle); 11 12 baseRadius = distance(point, center); 13 radius = baseRadius + (lines * y); 14 15 p1 ["x"] = roundValue(radius * Math.