大家好，我是楼仔呀。,无论大家工作还是面试，都会用到设计模式，如果不结合具体的场景，通过书本学到的设计模式非常容易忘。,本文通过具体的示例，教大家如何学习设计模式，保证你看完这篇文章后，这 3 种常用的设计模式，能妥妥掌握！,不 BB，上文章目录。,
,有个记者去南极采访一群企鹅，他问第一只企鹅：“你每天都干什么？”,企鹅说：“吃饭，睡觉，打豆豆！”,接着又问第 2 只企鹅，那只企鹅还是说：“吃饭，睡觉，打豆豆！”,记者带着困惑问其他的企鹅，答案都一样，就这样一直问了 99 只企鹅。,当走到第 100 只小企鹅旁边时，记者走过去问它：每天都做些什么啊？,那只小企鹅回答：”吃饭，睡觉．”,记者惊奇的又问：”你怎么不打豆豆？”,小企鹅撇着嘴巴，瞪了记者一眼说：”我就是豆豆！”,楼哥，你搞错了吧，这是篇技术文，你咋讲笑话了？甭着急，继续往后面看哈~~,我们会从简单到复杂，讲解代码正确的实现姿势，分别为最 Low 方式、常规方式、模板模式和策略模式。,2.1.1 最 Low 方式,假如现在有 3 只企鹅，都喜欢 “吃饭，睡觉，打豆豆”：,看一下执行结果：,这种方式是大家写代码时，最容易使用的方式，上手简单，也容易理解，目前看项目中陈旧的代码，经常能找到它们的影子，下面我们看怎么一步步将其进行重构。,2.1.2 常规方式,“吃饭，睡觉，打豆豆” 其实都是独立的行为，为了不相互影响，我们可以通过函数简单进行封装：,工作过一段时间的同学，可能会采用这种实现方式，我们有没有更优雅的实现方式呢？,2.1.3 模板模式,定义：一个抽象类公开定义了执行它的方法的方式/模板，它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行，属于行为型模式。,这 3 只企鹅，因为 “吃饭，睡觉” 都一样，所以我们可以直接实现出来，但是他们 “打豆豆” 的方式不同，所以封装成抽象方法，需要每个企鹅单独去实现 “打豆豆” 的方式。,最后再新增一个方法 everyDay()，固定每天的执行流程：,每只企鹅单独实现自己 “打豆豆” 的方式：,最后看调用方式：,楼哥，你这代码看的费劲，能给我画一个 UML 图么？来，安排！,
,2.1.4 策略模式,定义：一个类的行为或其算法可以在运行时更改，即我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象，策略对象改变 context 对象的执行算法，属于行为型模式。,我们还是先抽象出 3 个企鹅的行为：,每只企鹅单独实现自己 “打豆豆” 的方式：,这里就是策略模式的重点，我们再看一下策略模式的定义 “我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象”，那么该 contex 对象如下：,最后看调用方式：,我们可以通过给 behaviorContext 传递不同的对象，然后来约定 everyDay() 的调用方式。,其实我这个示例，有点把策略模式讲复杂了，因为纯粹的策略模式，3 个企鹅只有 beating() 方法不同，所以可以把 beating() 理解为不同的算法即可。,之所以引入 everyDay()，是因为实际的项目场景中，会经常这么使用，也就是把这个变化的算法 beating()，包装到具体的执行流程里面，所以策略模式就看起来没有那么直观，但是核心思想是一样的。,
,我在选择模板模式和策略模式时，发现两者都可以完全满足我的需求，然后我到网上查阅了很多资料，希望能找到两种模式在技术选择时，能确定告诉我哪些情况需要选择哪种模式。,说来惭愧，到现在我都没有找到，因为网上只告诉我两种实现姿势的区别，但是没有说明如何具体选型。,2.2.1 网上观点,据我可以告诉他们是 99％ 相同，唯一的区别是模板方法模式具有抽象类作为基类，而战略类使用由每个具体战略类实现的接口，两者的主要区别在于具体 algorithm 的 select。,使用 Template 方法模式时，通过子类化模板在编译时发生，每个子类通过实现模板的抽象方法提供了一个不同的具体 algorithm。,当客户端调用模板的外部接口的方法时，模板根据需要调用其抽象方法（其内部接口）来调用 algorithm。,相比之下，策略模式允许在运行时通过遏制来 select algorithm，具体 algorithm 是通过单独的类或函数实现的，这些类或函数作为 parameter passing 给构造函数或构造方法。,上面讲的有点抽象，下面直接看具体对比。,
,相似：,差异：,它基于接口；,客户和策略之间的耦合更加松散；,定义不能被子类改变的 algorithm 的骨架，只有某些操作可以在子类中重写；,父类完全控制 algorithm ，仅将具体的步骤与具体的类进行区分；,绑定是在编译时完成的。,它基于框架或抽象类，甚至可以有一个具有默认实现的具体类。,模块耦合得更紧密；,它通过修改方法的行为来改变对象的内容；,它用于在 algorithm 族之间切换；,它在运行时通过其他 algorithm 完全 replace 一个algorithm 来改变对象的行为；,绑定在运行时完成。,2.2.2 个人理解,对于有强迫症的我，没有找到问题的根源，总感觉哪里不对劲，我就说一下我对于两者区别的理解吧。,说实话，两种设计模式，我也就看到在实现姿势上有所区别，至于说的策略模式要定义统一接口，模板模式不这样做等，我不太赞同，因为我有时也会给模板模式定义一个通用接口。,然后也有人说，策略模式需要定义一堆对象，模板模式就不需要，如果有 10 个不同的企鹅，模板模式不也是需要定义 10 个不同的企鹅类，然后再专门针对特定的方法去实现么？,这两种设计模式，我感觉还没有到非此即彼的划分。,如果我没有固定的执行流程，比如只去打豆豆，只需要对一个方法做具体抽象，我愿意选择策略模式，因为这个我感觉会让我需要使用的对象，更清晰一些。,如果我有固定的执行流程，比如 “吃饭、睡觉、打豆豆”，我更愿意使用模板方法，可能是代码看多了，也看习惯了，更愿意用模板方法去规范代码固定的执行流程。,当然，我也可以将两者结合起来使用，比如我们可以用模板方法，去实现这 3 只企鹅，但是对于 middlePenguin，可能有分为企鹅少年 A、企鹅少年 B、企鹅少年 C，他们都喜欢隔壁的企鹅妹妹，但是喜欢的方式不同，有暗恋的，有直接表白的，还有霸道总裁的，我可以用策略模式，去指定他们对企鹅妹妹的表达方式。,任何模式，都需要结合实际的场景来讲，才能更清晰。,这两个模式，可以在你之前做过的项目中，只要稍微留意一下，应该会发现它们其实是大量存在的。,比如很多框架代码，里面有很多固定的执行流程，有些逻辑是可以采用默认处理的方式，有些逻辑需要下游自己去实现，然后有些逻辑还需要提前预留钩子。,比如在执行 process() 流程时，可能需要进行 preProcess() 的操作，那么这个 preProcess() 就是你预留的钩子，下游可以实现，也可以不实现。,后面会结合模板模式，来讲解工厂模式，实战场景非常强。,对于工厂模式，大家可能觉得会很 Low，不就是搞个类，然后专门生成一个具体的对象嘛，这有什么难的？,是的，工厂模式确实不难，但是问你一下，如果你的代码中有很多 if…else，你知道怎么通过工厂模式，把这些 if…else 去掉么？,嗯，工厂模式我会，但是和去掉 if…else 好像没有关系吧？,我举个例子，假如你遇到如下代码：,既然你懂工厂模式，可以把 if…else 简单重构一下，那就开始你的表演吧。,什么？不会？！你刚才还是自己是会工厂模式，怎么突然就怂了呢？,既然不会，那就静下心来，虚心学习一下。,定义：它提供了一种创建对象的最佳方式，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象，属于创建型模式。,先直接上图，后面的示例主要通过该图展开：,
,其实设计模式一般不会单一使用，通常会和其它模式结合起来使用，这里我们就将上一篇文章讲到的模板模式和工厂模式结合起来。,因为工厂模式，通常会给这些新创建的对象制定一个公共的接口，我们可以通过抽象类定义：,因为我们是结合了模板模式，所以这个抽象类中，可以看到模板模式的影子。,如果你只关注抽象的接口，比如 beating，那么这个就是一个抽象方法，也可以理解为下游需要实现的方法，其它的接口其实可以忽略。,看看每个企鹅具体的实现：,这里是工厂方法的重点，需要构建一个工厂，专门用来拿企鹅：,上面的逻辑很简单，就是通过一个 map 对象，放入所有的企鹅，这个工厂就可以通过企鹅的名字，拿到对应的企鹅对象，最后我们看使用方式：,输出如下：,楼哥，你这个例子我看懂了，但是你最开始抛的那个问题，能给出答案么？,文章开头的这个示例，其实也是我最近需要重构项目中的一段代码，我就是用 “工厂模式 + 模板模式” 来重构的。,我首先会对每个方法中的内容通过模板模式进行抽象（因为本章主要讲工厂模式，模板模式的代码，我就不贴了），然后通过工厂模式获取不同的对象，直接看重构后的代码：,这个场景就太多了，刚才给大家讲解的是去掉 if…else 的场景，然后在小米商城的支付系统中，因为海外有几十种支付方式，也是通过这种方式去掉 if…else 的，不过支付类的封装不是用的模板方法，用的的策略模式，虽然感觉两者差不多。,如果你直接 new 一个对象就能解决的问题，就用不到工厂模式了。,看完这篇文章，相信这 3 种设计模式，已经深深刻在你骨子里面了。,大家可以静下心来想想，自己之前做过的项目中，有哪些用到上面这 3 种设计模式，然后自己再结合具体的场景总结一下，我想你应该会有更深入的理解。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
