接口与设计原则

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原则: "Don't call us, we'll 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(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(!findInShape(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(findInShape(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    radAngle1 = Math.atan(slope(center, point1));
4    radAngle2 = Math.atan(slope(center, point2));
5    firstAngle = getStartAngle(radAngle1, point1, center);
6    secondAngle = getStartAngle(radAngle2, point2, center);
7    radAngle1 = 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(radAngle1) + center["y"]);
13    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
14    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
15    // Now some more code
16 }

很多开发者不愿意使用空白，就好像这要收费一样。我在此并非刻意地添加空白，粗鲁地打断代码的连贯性。在实际编写代码的过程中，会很容易地发现在什么地方加入空白，这不但美观而且让读者易懂，如下：
1 function getSomeAngle() {
2    // Some code here then
3    radAngle1 = Math.atan(slope(center, point1));
4    radAngle2 = Math.atan(slope(center, point2));
5
6    firstAngle = getStartAngle(radAngle1, point1, center);
7    secondAngle = getStartAngle(radAngle2, point2, center);
8
9    radAngle1 = degreesToRadians(firstAngle);
10    radAngle2 = degreesToRadians(secondAngle);
11
12    baseRadius = distance(point, center);
13    radius = baseRadius + (lines * y);
14
15    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
16    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
17
18    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
19    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
20    // Now some more code
21 }

4， 不要使用无谓的注释
无谓的注释让人费神，这实在很讨厌。不要标出很明显的注释。在以下的例子中，每个人都知道代码表达的是“students id”，因而没必要标出。
1 function existsStudent(id, list) {
2    for(i = 0; i < list.length; i++) {
3       student = list[i];
4
5       // Get the student's id
6       thisId = student.getId();
7
8       if(thisId === id) {
9           return true;
10       }
11    }
12    return false;  
13 }

5， 不要在源文件中留下已经删除的代码，哪怕你标注了
如果你使用了版本控制，那么你就可以轻松地找回前一个版本的代码。如果别人大费周折地读了你的代码,却发现是要删除的代码，这实在太恨人了。

//function thisReallyHandyFunction() {
//      someMagic();
//      someMoreMagic();
//      magicNumber = evenMoreMagic();
//      return magicNumber;
//}

6，不要有太长的代码

看太长的代码实在太费劲，尤其是代码本身的功能又很小。如下：

1 public static EnumMap<Category, IntPair> getGroupCategoryDistribution(EnumMap<Category, Integer> sizes, int groups) {
2        EnumMap<Category, IntPair> categoryGroupCounts = new EnumMap<Category,IntPair>(Category.class);
3
4        for(Category cat : Category.values()) {
5            categoryGroupCounts.put(cat, getCategoryDistribution(sizes.get(cat), groups));
6        }

#

我并不是说非要坚持70个字符以内，但是一个比较理想的长度是控制在120个字符内。如果你把代码发布在互联网上，用户读起来就很困难。
7，不要在一个功能（或者函数内）有太多代码行
我的一个老同事曾经说Visual C++很臭，因为它不允许你在一个函数内拥有超过10，000行代码。我记不清代码行数的上限，不知道他说的是否正确，但我很不赞成他的观点。如果一个函数超过了50行，看起来有多费劲你知道么，还有没完没了的if循环，而且你还的滚动鼠标前后对照这段代码。对我而言，超过35行的代码理解起来就很困难了。我的建议是超过这个数字就把一个函数代码分割成两个。

 

 

类的设计原则

2009-12-23 来源：lifevv.com

开闭原则 Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification. 软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。 开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其他程序单位时，应该遵循： - 对扩展开放（open） - 对修改关闭（closed） 的设计原则。 开闭原则是判断面向对象设计是否正确的最基本的原理之一。 根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。 - 扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。 - 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。 这也是系统设计需要遵循开闭原则的原因： 1）稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。 2）扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。 遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。 开闭原则的实现方法 为了满足开闭原则的 对修改关闭（closed for modification） 原则以及扩展开放（open for extension） 原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中， - 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展； - 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现； - 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。 接口可以被复用，但接口的实现却不一定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔软扩展。 简单地说，软件系统是否有良好的接口（抽象）设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。 开闭原则的相对性 软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块间的关系，都不会从一开始就非常清晰明了，所以构建100%满足开闭原则的软件系统是相当困难的，这就是开闭原则的相对性。但在设计过程中，通过对模块功能的抽象（接口定义），模块之间的关系的抽象（通过接口调用），抽象与实现的分离（面向接口的程序设计）等，可以尽量接近满足开闭原则。 单一职责原则 前言 Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles 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. 永远不要让一个类存在多个改变的理由。 换句话说，如果一个类需要改变，改变它的理由永远只有一个。如果存在多个改变它的理由，就需要重新设计该类。 SRP（Single Responsibility Principle）原则的核心含意是：只能让一个类有且仅有一个职责。这也是单一职责原则的命名含义。 为什么一个类不能有多于一个以上的职责呢？ 如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者（不同用户）： 1，一方面，如果一个职责使用了外部类库，则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。 2，另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。 这违反了设计的开闭原则，也不是我们所期望的。 职责的划分 既然一个类不能有多个职责，那么怎么划分职责呢？ 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的例子来说明怎么样进行职责的划分，这里我们也沿用这个例子来说明一下： 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个不同的接口，这样至少可以让客户端应用程序使用具有单一职责的接口： 让ModemImplementation实现这两个接口。我们注意到，ModemImplementation又组合了2个职责，这不是我们希望的，但有时这又是必须的。通常由于某些原因，迫使我们不得不绑定多个职责到一个类中，但我们至少可以通过接口的分割来分离应用程序关心的概念。 事实上，这个例子一个更好的设计应该是这样的，如图： 小结 Single Responsibility Principle (SRP)从职责（改变理由）的侧面上为我们对类（接口）的抽象的颗粒度建立了判断基准：在为系统设计类（接口）的时候应该保证它们的单一职责性。 接口分隔原则 前言 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层意思： - 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。 如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。 - 接口的依赖（继承）原则：如果一个接口a依赖（继承）另一个接口b，则接口a