001-设计原则

1      前言

23种设计模式，学了很多次，每次都是学完就忘。

忘，是应该的。这种术，重在用，而不是记。当然，学了、理解了，才会用得好。

网上有很多形象的例子、代码、视频，但实现方式上，很难说抓住了精髓，而且还受制于java语言本身（比如，很难在运行时扩展程序，annotation只是一种静态的标识，要达到目的，还需要一套复杂的解析过程。或许可以考虑使用groovy）。

更优雅地使用设计模式，更切合实际情况地完成功能，才能在学习的过程中，真正地理解。那时候，才是真懂了。

2       设计原则

面向对象五个基本原则（SOLID）

2.1   S-单一职责原则

Singleresponsibility principle，又称为单一功能原则。

如果一个类负责多个功能，那么，要修改任何一个功能时，都会对这个类里的其他功能带来风险。

此原则的核心就是解耦和增强内聚性。

2.1.1   反模式

做一个发送消息的功能。消息的内容、格式大体相同，但推送方式有三种：短信、邮件、站内信。其中，短信消息的标题、内容都需要合在一起，而且，尽量凝练，减少字数。不同的网关，发送的方式不同邮件针对不同的消息，可以使用不同的模板。比如：生日、嘉奖信等都有一套或多套模板，除了文字描述，还有图片、表格等。而且针对不同的邮箱，发送的协议也不同。站内信较自由的一种格式，就是普通的网页。但，由于WEB界面都是无状态的，需要定时刷新界面（或使用AJAX刷新局部界面），推送消息

public class MessageService{  public void send(Object o){  …}}

三种消息都使用Object封装，看似面向对象，实际上，就是一锅粥。

2.2   O-开闭原则

Open for extension，Closed for modification

增加新功能时，现有的代码，对扩展开放，对修改封闭。

2.2.1   反模式

简单工厂模式。例如，创建产品的工厂类，当新增产品时，就需要修改工厂类。

public IProduct getProduct(String name){IProduct product = null;//接口或抽象类，都可以switch(name){case "A":product = new A();break;case "B":product = new B();break;}return product;}

很显然，要增加新产品“C”时，就需要在switch里新增一条代码。

可以尝试修改代码，如下：

public IProduct getProduct(String className){return (IProduct)Class.forName(className).newInstance();}

2.3    L-里氏置换原则

Liskov Substitution Principle LSP。姓里的女士提出来的。

林先生在上课时风趣地称之为“老鼠的儿子会打洞”。^_^

2.3.1   反模式

老鼠的儿子不会打洞了，就违反了这个原则。

下面的示例，比较绕，可以忽略。

正方形是特殊的长方形

public class Rectangle{private int width;private int height;public Rectangle(int width,int height){this.width = width;this.height = height;}}public class Square extends Rectangle{public Square(int width,int height){this.width = width;this.height = width;/** * 或者 * this.width = height; * this.height = height; */}}

Square只需要一个属性，却从父类继承了两个。必须舍弃一个！

2.4   I-接口隔离原则

Interface Segregation Principle

拆分非常庞大臃肿的接口成为更小的和更具体的接口，从而容易重构，更改和重新部署。

2.5   D-依赖倒置原则

Dependence Inversion Principle

上下层之间，应该相互依赖于抽象出来的接口，而不是具体实现。更加精简的定义就是“面向接口编程”。

通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。如果没有实现这个原则，那么也就意味着开闭原则（对扩展开发，对修改关闭）也无法实现。

2.6   迪米特法则

又叫作最少知识原则（不和陌生人说话）。

一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心