Java程序员了解这45种设计模式与六大原则，让你面试大厂无忧

作为工程师，编码中一定会遇到以下问题：

如何分层、分模块？
如何划分类？类之间如何交互？
用继承还是组合？用接口还是抽象类？
怎样做到解耦、高内聚低耦合？
该用单例模式还是静态方法？
这些都是非常具体，非常常见的问题吧？

想要理解透设计模式的思想和原则，光看理论基本没用，结合源码阅读，才能事半功倍。

工厂模式

工厂模式（Factory Pattern）最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

意图： 定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

主要解决： 主要解决接口选择的问题。

何时使用： 我们明确地计划不同条件下创建不同实例时。

如何解决： 让其子类实现工厂接口，返回的也是一个抽象的产品。

关键代码： 创建过程在其子类执行。

应用实例：

1. 您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。

2. Hibernate 换数据库只需换方言和驱动就可以。

优点：

1. 一个调用者想创建一个对象，只要知道其名称就可以了。

2. 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。

3. 屏蔽产品的具体实现，调用者只关心产品的接口。

缺点： 每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

使用场景：

1. 日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。

2. 数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。

3. 设计一个连接服务器的框架，需要三个协议，“POP3”、“IMAP”、“HTTP”，可以把这三个作为产品类，共同实现一个接口。

注意事项： 作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

抽象工厂模式

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。

意图： 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

何时使用： 系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

如何解决： 在一个产品族里面，定义多个产品。

关键代码： 在一个工厂里聚合多个同类产品。

应用实例： 工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OO 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。

优点： 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。

缺点： 产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。

1. QQ 换皮肤，一整套一起换。

2. 生成不同操作系统的程序。

注意事项： 产品族难扩展，产品等级易扩展。

单例模式

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

注意：

· 1、单例类只能有一个实例。

· 2、单例类必须自己创建自己的唯一实例。

· 3、单例类必须给所有其他对象提供这一实例。

意图： 保证一个类仅有一个实例，并提供一个访问它的全局访问点。

主要解决： 一个全局使用的类频繁地创建与销毁。

何时使用： 当您想控制实例数目，节省系统资源的时候。

如何解决： 判断系统是否已经有这个单例，如果有则返回，如果没有则创建。

关键代码： 构造函数是私有的。

1. 一个班级只有一个班主任。

2. Windows 是多进程多线程的，在操作一个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。

3. 一些设备管理器常常设计为单例模式，比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。

4. 在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。

5. 避免对资源的多重占用（比如写文件操作）。

缺点： 没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

1. 要求生产唯一序列号。

2. WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。

3. 创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。

**注意事项：**getInstance 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化。

建造者模式

建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。

意图： 将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

主要解决： 主要解决在软件系统中，有时候面临着 “一个复杂对象” 的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。

何时使用： 一些基本部件不会变，而其组合经常变化的时候。

如何解决： 将变与不变分离开。

关键代码： 建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。

1. 去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的 “套餐”。

2. JAVA 中的 StringBuilder。

3. 建造者独立，易扩展。

4. 便于控制细节风险。

缺点：

1. 产品必须有共同点，范围有限制。

2. 如内部变化复杂，会有很多的建造类。

3. 需要生成的对象具有复杂的内部结构。

4. 需要生成的对象内部属性本身相互依赖。

注意事项： 与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。

由于篇幅限制，小编这里暂时只分享以上三种模式，完整版的45种设计模式于六大原则小编已经整理成了一份pdf文档了，方便大家查阅，那么要如何获取到这分资料呢？

来自8年开发老码农福利赠送：如果你对前端开发这门技术感兴趣，我自己整理的一份2019年最新前端学习资料，从最基础的HTML+CSS到各种框架和项目实战的资料都有整理，送给每一位学习前端的小伙伴。

领取微信：abusiabusi