设计模式篇

设计模式篇口语回答

本篇记录了关于设计模式的口语话回答

讲讲策略模式

策略模式(Strategy Pattern)是一种行为设计模式，主要是将一些共性的方法进行抽取，并提供一个可以进行决策选择的方法，从而进行解耦的快速开发;

平时我们在工作中也能在大量的场景中使用到策略模式，就拿一个营收平台奖励发放的案例来说，一个平中其实存在许许多多的奖励类型比如实物奖励、VIP奖励、代金券奖励、优惠券奖励、现金奖励等等，我们在进行方案设计评估的时候应该也能设想到作为奖励模块随着系统的不断更新迭代会有越来越多的奖励类型加入进来,那么我们在设计这个模块的时候就可以将奖励发放这块逻辑抽象为公性方法，通过每种奖励类型作为决策条件，然后通过不同的决策条件就可以定位到实际的奖励发放逻辑。这样做的好处主要是解耦、基本上可以实现每一种奖励都对应一个奖励发放处理类，后续有需要添加新的奖励类型只要添加对应的奖励发放处理即可，同时对于测试同学来说，他们也不用当心因为你们加多了新的奖励类型而需要去回归之前的所有奖励发放流程。同时也将不同业务进行了类隔离。弊端则是代码编写量会增多，在某些场景下可能会产生类爆炸之类的问题。

讲讲建造者模式

构建者模式(Builder Pattern)是一种创建型设计模式，它通过一步一步地构建复杂对象，从而将对象的构建过程与表示分离。

在我们平时的工作中比较常见的构建者模式主要提现在lombok 的@builder 注解以及我们在创建一些复杂对象的时候我们就会使用到构建者模式，比如在@builder 的常见下主要的作用就是用户简化对象的构建，我们使用 builder 的形式可以让我们使用链式变成编程的形式一步一步的构建我们的对象，避免了在代码中大量的去调用 set 方法去对象，提高了代码的没关程度;就拿我们的业务系统而言我们也会在创建一些复杂对象的情况下去使用构建者模式，比如在我们的一个活动营收抽奖系统来说的，我们往往要及时提醒业务方活动产出的-样些高价值奖励，比如现金奖励，大额优惠元等等，因此我们基本上会考虑给业务所在的公司内部钉钉群、企业微信群及时推送一些产出相关的消息，同时我们为了让消息显示的更加简洁我们往往不会推送一个简单的文案而是推送一个 markdown 文本消息，这个 markdown 文本消息对于我们来说就可以算的上一个复杂对象因此我们就可以通过使用构建者模式加上内部类的形式来构建这个对象，通过内部类 builder 去简化掉我们构建 markdown 对象的创建过程

好处是我们可以暴露出简单的构建者 api 去构建复杂的对象。

缺点的就是如果在一些简单的对象上去滥用构建者模式，除了会增加内存中的对象个数也会增加代码的可读程度。

讲讲模版方法模式

模板方法模式(Template Method Pattern) 是一种行为设计模式，它定义了一个操作中的算法的骨架，而将-些步骤延迟到子类中。通过这种方式，子类可以在不改变算法结构的情况下重新定义算法中的某些步骤。平时在我们工作的也有不少地方可以使用到模板方法模式，就拿活动营收的抽奖系统来说，我们就可以使用的上模板方法模式;抽奖的主要流程基本就是 校验用户的合法性 > 校验奖池的合法性 >用户抽检次数的扣减>用户进行抽奖 >奖励发放 >抽奖明细落地 > 抽奖预警及监控，因此我们在设计这个模块的时候我们就可以使用模板方法把上边的这些流程都弄成一个骨架，并配合接口的默认实现、抽象类的默认实现我们就可以提供好-些默认的业务功能，同时当子类业务觉得某些骨架中的方法可能不大适合自己的业务场景的时候，就可以通过重写的方法去覆盖掉这些方法，从而实现对复杂业务的解耦。

优点的话，主要是定义了一个通用骨架，并且合理利用了多态的特点，可以灵活的快速的去兼容业务的迭代变季 弊端的话主要也还是增加了代码编码难度，同时在配合多态的情况下对于新手可能不大友好，可能第一眼不能理解到，业务的调用过程:

讲讲单例模式

单例模式(Singleton Pattern)是一种创建型设计模式，它确保一个类只有一个实例，并提供全局访问点。单例模式在许多情况下非常有用，尤其是当需要一个全局对象来协调系统操作时。

平时我们接触对多的单例模式应该属于 spring 的 ioc 容器中的单例对象，使用 spring 中的单例 bean 可以让我们日常的开发中，可以直接的将我们的单例 bean 注入到我们各自的业务类中，避免了在我们不同的业务类中大量的重复的去构建这一些 bean。以及我们某一些线程安全的常见下，如果所有的对象共同来调用这个类中的方法不会导致数据及业务异常，以及不想或者在不能映入 spring ioc 的情况下我们就可以使用注入枚举、内部类、饿汉、饱汉等机制来实现我们的一个单例模式。就拿营收系统的奖池产出预警这个场景来说，我们不同的业务可能会关注钉钉的消息有些人可能关注企业微信群的消息，这样我们就可以真正的发送不同消息的出来通过枚举的形式来实现一个单例 bean。

讲讲适配器模式

适配器模式是一种结构型设计模式，它使得接口不兼容的类可以一起工作，即通过将一个类的接口转换成客户端期望的另一个接口，使原本因接口不匹配而无法一起工作的类可以协同工作。

平时在我们工作中使用的比较多的可能是对不同数据的处理，将不同数据的适配成我们可以统一使用的数据比如活动营收系统中的任务模块，往往触发任务的都是一些列不同的消息，比如用户登陆消息、充值消息、心跳消息等等，这时候我们就可以使用适配器模式通过把不同的消息处理成任务处理器可以统一处理的TaskContext 从而可以让任务处理器去统一处理不同的任务类型;同时我们在做一些第三方依赖 jar 的切换的时候我们也可以通过适配器模式将不同 jar 里边的提供的接口适配统一接口，比如系统中以前依赖的redis 客户端是 jedis 现在需要替换成 redisson 这时候我们就可以在 上层抽取一个适配器接口，然后分别用 jedis 和redisson 的实现去实现适配器接口的暴露出来的接口，就可以实现第三方依赖 jar 的快速切换。

讲讲模板模式

说明：在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板，它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行（属于行为型模式）

意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中；模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

主要解决：一些方法通用，却在每一个子类都重新写了这一方法。

何时使用：有一些通用的方法。

如何解决：将这些通用算法抽象出来（关键代码在抽象类实现，其他步骤在子类实现）

应用实例： 1）在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2）西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3）Spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。

优点：1）封装不变部分，扩展可变部分。 2）提取公共代码，便于维护。 3）行为由父类控制，子类实现。

缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。

使用场景：1）有多个子类共有的方法，且逻辑相同。 2）重要的、复杂的方法，可以考虑作为模板方法。

注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。

讲讲工厂模式

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

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

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

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

如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品（创建过程在其子类执行）

应用实例：1）您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2）Hibernate 换数据库只需换方言和驱动就可以。

优点：1）一个调用者想创建一个对象，只要知道其名称就可以了。 2）扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3）屏蔽产品的具体实现，调用者只关心产品的接口。

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

使用场景：1）日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。 2）数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3）设计一个连接服务器的框架，需要三个协议，" POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。

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

讲讲抽象工厂模式

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

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

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

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

如何解决：在一个产品族里面，定义多个产品（在一个工厂里聚合多个同类产品）

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

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

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

使用场景：1）QQ 换皮肤，一整套一起换。 2）生成不同操作系统的程序。

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

讲讲策略模式

说明：在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。

何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。

如何解决：将这些算法封装成一个一个的类，任意地替换（实现同一个接口）

应用实例： 1）诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2）旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3）JAVA AWT 中的 LayoutManager。

优点：1）算法可以自由切换。 2）避免使用多重条件判断。 3）扩展性良好。

缺点：1）策略类会增多。 2）所有策略类都需要对外暴露。

使用场景：1）如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2）一个系统需要动态地在几种算法中选择一种。 3）如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。

注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。

讲讲责任链模式

概念说明： 在责任链模式中，通常会有多个处理者对象（也称为处理器或者节点），它们按照某个顺序组成一个链。客户端向该链的开头发送请求，并沿着链传递直到有一个处理者能够处理该请求。每个处理者都有机会处理请求，如果一次请求不能被任何处理者处理，则请求将最终无法处理。

说明：如果我们要实现一串复杂的规则校验，本来可能由一长串的 if-else 的判断来实现，但是如果校验规则非常复杂，使用 if-else 非常的不优雅，于是我们可以使用责任链模式来实现！

案例说明：我们创建一个作品的实体类，我们使用责任链模式对其中的标题和内容进行校验