设计模式6原则

1.开闭原则，简言之：对扩展开放，对修改关闭，
2.单一职责原则，一个类只负责一项指责，好比：User是一个职责，Order是一个职责
3.里氏替换原则(LSP)：

3.1子类能够按需扩展自由功能
3.2不修改父类原有功能。若是是继承而非实现的时候，少用@override

4.依赖倒转原则：

引用文字设计模式六大原则（3）：依赖倒置原则
定义
问题由来
解决方案
定       义：高层模块不该该依赖低层模块，两者都应该依赖其抽象；抽象不该该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改成依赖类C，则必须经过修改类A的代码来达成。这种场景下，类A通常是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操做；假如修改类A，会给程序带来没必要要的风险。

解决方案：将类A修改成依赖接口O，类B和类C各自实现接口O，类A经过接口O间接与类B或者类C发生联系，则会大大下降修改类A的概率。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在Java中，抽象指的是接口或者抽象类，细节就是实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操做，把展示细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程，咱们依然用一个例子来讲明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她（母亲）一本书，她就能够照着书给孩子讲故事了。代码以下：

class Book{

public String getContent(){
    return "好久好久之前有一个阿拉伯的故事......";

}
}

class Mother{

public void narrate(Book book){
    System.out.println("妈妈开始讲故事了。");

}
}

public class Client{

public static void main(String[] args){
    Mother mother = new Mother();
    mother.narrate(new Book());

}
}
运行结果：

妈妈开始讲故事
好久好久之前有一个阿拉伯的故事......
运行良好，假设有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码以下：

class Newspaper{

public String getContent(){
   return "林书豪38+7领导尼克斯击败湖人......";

}
}
咱们发现这位母亲却办不到，由于她竟然不会读报纸上的故事，这太荒唐了，只是将书换成了报纸，竟然要咱们必须修改Mother类才能读。假如之后需求换成杂志呢，换成网页呢？难道每换一次都要咱们修改一次Mother类吗？这显然不是最好的设计。缘由就是Mother与Book之间的耦合性过高了，必须下降他们的耦合度才行。

咱们引入一个抽象的接口IReader。读物，包括咱们的博客文章，只要是带字的都是读物。代码以下：

interface IReader{

public String getContent();

}
Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改成：

/**
*让Newspaper去实现IReader这个接口
*/
class Newspaper implements IReader{

public String getContent(){
    return "林书豪17+9助尼克斯击败湖人......";

}
}

/**
*让Book类也去实现IReader这个借口
*/
class Book implements IReader{

public String getContent(){
    return "好久好久之前有一个阿拉伯的故事......";

}
}

class Mother{

public void narrate(IReader ireader){
   System.out.println("妈妈开始讲故事了");
   System.out.println(ireader.getContent());

}
}

/**
*测试类
*/
public class Client{

public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book);
mother.narrate(new Newspaper());

}
}
运行结果：

妈妈开始讲故事
好久好久之前有一个阿拉伯的故事......
妈妈开始讲故事
林书豪17+9助尼克斯击败湖人......
这样修改以后，不管之后怎样扩展Client类，都不须要再去修改Mother类了，这只是一个简单的例子，实际状况中，表明高层模块中的Mother类将负责完成主要的业务逻辑，一旦须要对它进行修改，引入错误的风险极大。索引遵循依赖倒置原则能够下降类之间的耦合性，提升系统的稳定性，下降修改程序形成的风险。

采用依赖倒置原则给多人并行开发带来了极大的便利，好比上面的例子中，本来Mother类和Book类直接耦合时，Mother必须等Book类编码完成以后才能够进行编码，由于Mother类依赖于Book类。修改后的程序则能够同时开工，互相不影响，由于Book类和这个Mother类一丁点关系也没有啊。参与协做开发的人越多，项目越庞大，采用依赖倒置原则的意义也就显得尤其重要。有个很流行的TDD开发模式就是引来倒置原则最成功的应用。

传递依赖关系有三种方式，以上的例子中使用的方法时接口传递，另外还有两种传递方式：构造方法的传递和setter()方法的传递，相信用过Spring框架的，对依赖的传递方式必定不会陌生。

在实际编程中，咱们通常须要作到如下三点就OK：

低层模式尽可能都要有抽象类和接口，或者二者都有。
变量的声明类型尽可能是抽象类和接口。
使用继承的时间遵循里氏替换原则。

依赖倒置原则的核心就是要咱们面向接口编程，理解了面向接口编程，也就慢慢理解了依赖倒置原则。

做者：Java_Yangxiaoyuan
来源：CSDN
原文：https://blog.csdn.net/java_ya...
版权声明：本文为博主原创文章，转载请附上博文连接！

5.接口隔离原则6.迪米特法则