23 种设计模式和 6 大设计原则

设计模式

什么是设计模式？

设计模式指的是一套被反复使用、多数人知晓的、过过分类编目的、代码设计经验的总结

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模 式、状态模式、访问者模式、中介者模式、解释器模式。

设计模式的六大原则

1. 开闭原则（Open Close Principle）

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类
代码案例

public class Shape {
    int shapeType;
}
class Circle extends Shape{
    public Circle() {
        shapeType=1;
    }
}
class Rectangle extends Shape{
    public Rectangle() {
        shapeType=2;
    }
}

class GrapicEditor{
    public void drawShape(Shape s){
        if (s.shapeType==1){
            drawCircle(s);
        }else if (s.shapeType==2){
            drawRectangle(s);
        }
    }

    private void drawRectangle(Shape s) {
        System.out.println("drawRectangle...");
    }

    private void drawCircle(Shape s) {
        System.out.println("drawCircle...");
    }
}

/**
 *
 * Shape 的方法改进
 * 改进思路：将Shape类改进为抽象类，并提供一个抽象方法draw方法，让子类去实现即可，这样有新的图形种类时，
 * 只需要让新的图形类继承Shape，并实现draw方法即可，使用方的代码就不需要修改，满足开闭原则。
 */
public interface ShapeImprove {

    void draw();
}

class CircleImprove implements ShapeImprove{

    @Override
    public void draw() {
        System.out.println("CircleDraw....");
    }
}
class RectangleImprove implements ShapeImprove{

    @Override
    public void draw() {
        System.out.println("Rectangle....");
    }
}

class GrapicEditorImprove{

    public void drawShape(ShapeImprove s){
        s.draw();
    }
}

2. 里氏代换原则（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏
子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。
子类在设计的时候，要遵守父类的行为约定（或者叫协议）。
父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定。
这里的行为约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。
实际上，定义中父类和子类之间的关系，也可以替换成接口和实现类之间的关系。

3. 依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
依赖倒置的定义： 高层模块不应该依赖底层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

类A是高层模块，负责复杂的业务逻辑；
类B和类C是低层模块，负责基本的原子操作；

先看代码理解什么是依赖倒置原则：

//首先先看不是面向接口编程的代码
/**
* 场景：母亲给孩子讲故事，只要给她一本书，他就可以照着书给孩子讲故事了
*/

class Book{  
       public String getContent(){  
           return "很久很久以前有一个阿拉伯的故事……";  
       }  
   }  
     
   class Mother{  
       public void narrate(Book book){  
           System.out.println("妈妈开始讲故事");  
           System.out.println(book.getContent());  
       }  
   }  
     
   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接口，这样就符合依赖倒置原则了，代码修改为：

class Newspaper implements IReader {  
       public String getContent(){  
           return "林书豪17+9助尼克斯击败老鹰……";  
       }  
   }  
   class Book implements IReader{  
       public String getContent(){  
           return "很久很久以前有一个阿拉伯的故事……";  
       }  
   }  
     
   class Mother{  
       public void narrate(IReader reader){  
           System.out.println("妈妈开始讲故事");  
           System.out.println(reader.getContent());  
       }  
   }  
     
   public class Client{  
       public static void main(String[] args){  
           Mother mother = new Mother();  
           mother.narrate(new Book());  
           mother.narrate(new Newspaper());  
       }  
   }

这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。
上例中，原本Mother类与Book类直接耦合时，Mother类必须等Book类编码完成后才可以进行编码，因为Mother类依赖于Book类。修改后的程序则可以同时开工，互不影响，因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。

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

解决方案： 将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

4. 接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
客户端不应该依赖它不需要的接口。（此处接口分为实例接口即类，类接口 interface，所以此处的接口在 java 中是类和接口的意思）
建立单一的接口，不要建立臃肿庞大的接口，与 SRP 的区别：SRP 针对职责，从业务逻辑划分；ISP 是要求接口的方法尽量少。

接口尽量小
接口要高内聚
高内聚：提高接口、类、模块的处理能力，减少对外的交互，要求在接口中尽少公布 public 方法，减少对外承诺也有利于降低成本
定制服务，针对不同的用户提供优良的服务，只提供访问者需要的方法。如不同权限的用户给于不同的操作接口。
接口设计有限度的
接口粒度越小，越灵活，但是结构却越复杂，所以要有个度

5. 迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
也称为最少知识原则（Least Knowledge Principle，LKP）：
一个对象应该对其他对象有最少的了解。对类的低耦合提出了明确的要求

只和朋友交流。
例：老师叫班长清点学生，老师应该只和班长有耦合，而不应该和学生有耦合。
朋友之间也是有距离的。
耦合的类不要把太多方法暴露给其它类，否则改动要修改的地方太多。（高内聚）
自己的就是自己的
如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

6. 单一职责原则（Single Responsibility Principle）

一个类/接口/方法 只负责一项职责
优点： 降低类的复杂度、提高类的可读性，提高系统的可维护性、降低变更引起的风险。

最后

以上就是眼睛大大山最近收集整理的关于23种设计模式和 6 大设计原则23 种设计模式和 6 大设计原则的全部内容，更多相关23种设计模式和内容请搜索靠谱客的其他文章。