设计原则

设计原则，有比较规范的定义，可能或多或少都听说过。

1.单一职责原则：就一个类而言，应该只有一个引起它变化的原因。

举个例子，如果开发一个计算器小程序，开始肯定有不少人一个类就搞定了。这个类就违反了单一职责原则，因为这个类不但有计算逻辑，还用来显示了。所以除了计算外，显示也会引起这个类的变化。如果现在想改成控制台程序呢？容易改吗？

2.开-闭原则：软件实体（类，方法等），应该可以扩展，但不能修改。

这句话应该比较熟悉，“对修改关闭，对扩展开放”。具体是什么意思呢？还是上面的计算器，如果还是那个类，想改成控制台程序。那么就需要修改类了，这就违背开闭原则了。理想状态是添加一个新的功能（这里就是控制台输出），替换掉可视化即可，稍微的修改是可以容忍的或者是必须的。

在说一个情况，如果你写了一个程序，给另一个人用，没办法扩展，于是那个人就修改你的代码，然后过了几天你想到一个新功能，想拿回来修改，发现面目全非了，你什么感受。倒过来，别人给你的代码你只能修改他的代码才能用，你又是什么感受？

3.依赖倒转原则：

（1）高层模块不应该依赖底层模块。两个都应该依赖抽象。

（2）抽象不应该依赖细节。细节应该依赖抽象。

（2）就类似于学OO时长听到的一句话，面向接口编程。其实(1)也是这个意思，还是上面那个计算器，假设你和另一个人协作开发，一人写前台，一人写计算逻辑。该怎么协作呢？你写算法逻辑，还要那人等你写完了再写前台吗？这时可以定义一套接口，你实现接口，而他调用接口就可以了，而不必管你实现了没有。

4.里氏替换原则：子类应该能替换掉它的父类。

乍看之下，这好像是理所当然的。举个例子就明白了。

例如，你有一个Bird类，如下所示。

程序代码：
public class Bird{

public void fly(){

System.out.println("飞翔");

}

public void sound(){

System.out.println("鸣叫");

}

}
然后呢，你有一个燕子类继承了Bird类

程序代码：

public class Swallow extends Bird{

........

}
接着呢！调用

程序代码：

public class Test{

public static void main(String [] args){

Bird bird = new Swallow();

bird.fly();

bird.sound();

}

}
这个代码很明了吧？如果现在有个鸽子类，需要怎么样呢？Bird类不需要改，Swallow也不需要改，这就对修改关闭了，添加一个鸽子类，继承Bird类，然后在main方法里面将new Swallow()替换掉即可。这就是对扩展开放了。而如果这时候，你需要添加一个企鹅类，你还能这么添加吗？肯定就不能了。为什么呢？因为企鹅虽然是鸟类，但是不能继承Bird类，因为企鹅不会fly()。既然不会fly，那么在Test类里面，它就不能替换掉Bird类了，如果替换掉了，那么fly()就没有了。这个就是里氏替换原则。

5.迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果一个类需要调用另一个类的某个方法，可以通过第三者转发这个调用。

这个原则简单来说就是类要强内聚松耦合。类与类之间耦合越松，越容易复用。其实这个原则和依赖倒转原则很类似。

知道了这些原则，写程序的时候，多思考思考，不断的向这个方向重构，那么设计模式就自然而然的出现在你眼前了