# lasse-designPattern
**Repository Path**: luosuichuan/lasse-design-pattern
## Basic Information
- **Project Name**: lasse-designPattern
- **Description**: 学习设计模式
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-12-02
- **Last Updated**: 2023-01-17
## Categories & Tags
**Categories**: Uncategorized
**Tags**: 设计模式
## README
# lasse-design-pattern
# 介绍
学习设计模式
#项目名称介绍
后缀为：
-scene ->表示业务代码
如：
adapter-pattern-scene -> 适配器模式的业务场景
后缀为：-before ->表示用设计模式之前，形成强烈对比性
如：
adapter-pattern-before ->使用适配器模式前的实现方式
无后缀的： ->表示设计模式的实现方式
如：
adapter-pattern ->适配器模式实现方式
#第一章、工厂模式（人民币银行兑换外币）
##一、前言
好看的代码千篇一律，恶心的程序升职加薪。
该说不说几乎是程序员就都知道或者了解设计模式，但大部分小伙伴写代码总是习惯于一把梭。无论多少业务逻辑就一个类几千行，这样的开发也可以归纳为三步；定义属性、创建方法、调用展示，Done！只不过开发一时爽，重构火葬场。
好的代码不只为了完成现有功能，也会考虑后续扩展。在结构设计上松耦合易读易扩展，在领域实现上高内聚不对外暴漏实现细节不被外部干扰。而这就有点像家里三居(MVC)室、四居(DDD)室的装修，你不会允许几十万的房子把走线水管裸漏在外面，也不会允许把马桶放到厨房，炉灶安装到卫生间。
其实有一部分人并没有仔细阅读过设计模式的相关书籍和资料，但依旧可以编写出优秀的代码。这主要是由于在经过众多项目的锤炼和对程序设计的不断追求，从而在多年编程历程上提炼出来的心得体会。而这份经验最终会与设计模式提到的内容几乎一致，同样会要求高内聚、低耦合、可扩展、可复用。你可能也遇到类似的经历，在学习一些框架的源码时，发现它里的某些设计和你在做开发时一样。
我怎么学不会设计模式？ 钱也花了，书也买了。代码还是一坨一坨的！设计模式是由多年的经验提炼出来开发指导思想。就像我告诉你自行车怎么骑、汽车怎么开，但只要你没跑过几千公里，你能记住的只是理论，想上道依旧很慌！
##二、工厂方法模式介绍
工厂模式又称工厂方法模式，是一种创建型设计模式，其在父类中提供一个创建对象的方法， 允许子类决定实例化对象的类型。
这种设计模式也是 Java 开发中最常见的一种模式，它的主要意图是定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
简单说就是为了提供代码结构的扩展性，屏蔽每一个功能类中的具体实现逻辑。让外部可以更加简单的只是知道调用即可，同时，这也是去掉众多ifelse的方式。当然这可能也有一些缺点，比如需要实现的类非常多，如何去维护，怎样减低开发成本。但这些问题都可以在后续的设计模式结合使用中，逐步降低。
##三、模拟去银行兑换外币
为了可以让整个学习的案例更加贴近实际开发，这里模拟互联网中在营销场景下的业务。由于营销场景的复杂、多变、临时的特性，它所需要的设计需要更加深入，否则会经常面临各种紧急CRUD操作，从而让代码结构混乱不堪，难以维护。
##四、用一坨坨代码实现
请看 factory-pattern-before 模块
- 如上就是使用 ifelse 非常直接的实现出来业务需求的一坨代码，如果仅从业务角度看，研发如期甚至提前实现了功能。
- 那这样的代码目前来看并不会有什么问题，但如果在经过几次的迭代和拓展，接手这段代码的研发将十分痛苦。重构成本高需要理清之前每一个接口的使用，测试回归验证时间长，需要全部验证一次。这也就是很多人并不愿意接手别人的代码，如果接手了又被压榨开发时间。那么可想而知这样的 ifelse 还会继续增加。
##五、工厂模式优化代码
请看 factory-pattern 模块
- 运行结果正常，既满足了业务产品需求，也满足了自己对代码的追求。这样的代码部署上线运行，内心不会恐慌，不会觉得半夜会有电话。
- 另外从运行测试结果上也可以看出来，在进行封装后可以非常清晰的看到一整套兑换服务的完整性，统一了入参、统一了结果。
##六、总结
- 从上到下的优化来看，工厂方法模式并不复杂，甚至这样的开发结构在你有所理解后，会发现更加简单了。
- 那么这样的开发的好处知道后，也可以总结出来它的优点；避免创建者与具体的产品逻辑耦合、满足单一职责，每一个业务逻辑实现都在所属自己的类中完成、满足开闭原则，无需更改使用调用方就可以在程序中引入新的产品类型。但这样也会带来一些问题，比如有非常多的奖品类型，那么实现的子类会极速扩张。因此也需要使用其他的模式进行优化，这些在后续的设计模式中会逐步涉及到。
-从案例入手看设计模式往往要比看理论学的更加容易，因为案例是缩短理论到上手的最佳方式，如果你已经有所收获，一定要去尝试实操。
#第二张、抽象工厂模式
##前言
代码一把梭，兄弟来背锅。
大部分做开发的小伙伴初心都希望把代码写好，除了把编程当作工作以外他们还是具备工匠精神的从业者。但很多时候又很难让你把初心坚持下去，就像；接了个烂手的项目、产品功能要的急、个人能力不足，等等原因导致工程代码臃肿不堪，线上频出事故，最终离职走人。
看了很多书、学了很多知识，多线程能玩出花，可最后我还是写不好代码！
这就有点像家里装修完了买物件，我几十万的实木沙发，怎么放这里就不好看。同样代码写的不好并不一定是基础技术不足，也不一定是产品要得急 怎么实现我不管明天上线。而很多时候是我们对编码的经验的不足和对架构的把控能力不到位，我相信产品的第一个需求往往都不复杂，甚至所见所得。但如果你不考虑后续的是否会拓展，将来会在哪些模块继续添加功能，那么后续的代码就会随着你种下的第一颗恶性的种子开始蔓延。
学习设计模式的心得有哪些，怎么学才会用！
设计模式书籍，有点像考驾驶证的科一、家里装修时的手册、或者单身狗的恋爱宝典。但！你只要不实操，一定能搞的乱码七糟。因为这些指导思想都是从实际经验中提炼的，没有经过提炼的小白，很难驾驭这样的知识。所以在学习的过程中首先要有案例，之后再结合案例与自己实际的业务，尝试重构改造，慢慢体会其中的感受，从而也就学会了如果搭建出优秀的代码。
##抽象工厂模式介绍
是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
##案例场景模拟
预估QPS较低、系统压力较小、并发访问不大、近一年没有大动作等等，在考虑时间投入成本的前提前，并不会投入特别多的人力去构建非常完善的系统。就像对 Redis 的使用，往往可能只要是单机的就可以满足现状。
不吹牛的讲百度首页我上学时候一天就能写完，等毕业工作了就算给我一年都完成不了！
但随着业务超过预期的快速发展，系统的负载能力也要随着跟上。原有的单机 Redis 已经满足不了系统需求。这时候就需要更换为更为健壮的Redis集群服务，虽然需要修改但是不能影响目前系统的运行，还要平滑过渡过去。
##总结
- 抽象工厂模式，所要解决的问题就是在一个产品族，存在多个不同类型的产品(Redis集群、操作系统)情况下，接口选择的问题。而这种场景在业务开发中也是非常多见的，只不过可能有时候没有将它们抽象化出来。
- 你的代码只是被ifelse埋上了！当你知道什么场景下何时可以被抽象工程优化代码，那么你的代码层级结构以及满足业务需求上，都可以得到很好的完成功能实现并提升扩展性和优雅度。
- 那么这个设计模式满足了；单一职责、开闭原则、解耦等优点，但如果说随着业务的不断拓展，可能会造成类实现上的复杂度。但也可以说算不上缺点，因为可以随着其他设计方式的引入和代理类以及自动生成加载的方式降低此项缺点。
#第三章、建造者模式「各项装修物料组合套餐选配场景」
##前言
乱码七糟 [luàn qī bā zāo]，我时常怀疑这个成语是来形容程序猿的！
无论承接什么样的需求，是不是身边总有那么几个人代码写的烂，但是却时常有测试小姐姐过来聊天(求改bug)、有产品小伙伴送吃的(求写需求)、有业务小妹妹陪着改代码(求上线)，直至领导都认为他的工作很重要，而在旁边的你只能蹭点吃的。
那你说，CRUD的代码还想让我怎么样？
这样的小伙伴，可能把代码写的很直接，ifelse多用一点，满足于先临时支持一下，想着这也没什么的。而且这样的业务需求要的急又都是增删改查的内容，实在不想做设计。而如果有人提到说好好设计下，可能也会被反对不要过度设计。
贴膏药似的修修补补，一次比一次恐怖！
第一次完成产品需求实在是很快，但互联网的代码不比传统企业。在传统行业可能一套代码能用十年，但在互联网高速的迭代下你的工程，一年就要变动几十次。如果从一开始就想着只要完成功能就可以，那么随之而来的是后续的需求难以承接，每次看着成片成片的代码，实在不知如何下手。
在研发流程规范下执行，才能写出好程序！
一个项目的上线往往要经历业务需求、产品设计、研发实现、测试验证、上线部署到正式开量，而这其中对研发非常重要的一环就是研发实现的过程，又可以包括为；架构选型、功能设计、设计评审、代码实现、代码评审、单测覆盖率检查、编写文档、提交测试。所以在一些流程规范下，其实很难让你随意开发代码。
开发代码的过程不是炫技，就像盖房子如果不按照图纸来修建，回首就在山墙上搭一个厨房卫浴！可能在现实场景中这很荒唐，但在功能开发中却总有这样的代码。
所以我们也需要一些设计模式的标准思想，去建设代码结构，提升全局把控能力。
##建造者模式介绍
建造者模式所完成的内容就是通过将多个简单对象通过一步步的组装构建出一个复杂对象的过程。
那么，哪里有这样的场景呢？
例如你玩王者荣耀的时的初始化界面；有三条路、有树木、有野怪、有守卫塔等等，甚至依赖于你的网络情况会控制清晰度。而当你换一个场景进行其他不同模式的选择时，同样会建设道路、树木、野怪等等，但是他们的摆放和大小都有不同。这里就可以用到建造者模式来初始化游戏元素。
而这样的根据相同的物料，不同的组装所产生出的具体的内容，就是建造者模式的最终意图，也就是；将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
##案例场景模拟
这里我们模拟装修公司对于设计出一些套餐装修服务的场景。
很多装修公司都会给出自家的套餐服务，一般有；欧式豪华、轻奢田园、现代简约等等，而这些套餐的后面是不同的商品的组合。例如；一级&二级吊顶、多乐士涂料、圣象地板、马可波罗地砖等等，按照不同的套餐的价格选取不同的品牌组合，最终再按照装修面积给出一个整体的报价。
这里我们就模拟装修公司想推出一些套餐装修服务，按照不同的价格设定品牌选择组合，以达到使用建造者模式的过程。
##总结
- 通过上面对建造者模式的使用，已经可以摸索出一点心得。那就是什么时候会选择这样的设计模式，当：一些基本物料不会变，而其组合经常变化的时候，就可以选择这样的设计模式来构建代码。
- 此设计模式满足了单一职责原则以及可复用的技术、建造者独立、易扩展、便于控制细节风险。但同时当出现特别多的物料以及很多的组合后，类的不断扩展也会造成难以维护的问题。但这种设计结构模型可以把重复的内容抽象到数据库中，按照需要配置。这样就可以减少代码中大量的重复。
- 设计模式能带给你的是一些思想，但在平时的开发中怎么样清晰的提炼出符合此思路的建造模块，是比较难的。需要经过一些锻炼和不断承接更多的项目，从而获得这部分经验。有的时候你的代码写的好，往往是倒逼的，复杂的业务频繁的变化，不断的挑战！
#第四章、原型模式「上机考试多套试，每人题目和答案乱序排列场景」
##前言
老板你加钱我的代码能飞
程序员这份工作里有两种人；一类是热爱喜欢的、一类是仅当成工作的。而喜欢代码编程的这部分人会极其主动学习去丰富自己的羽翼，也非常喜欢对技术探索力求将学到的知识赋能到平时的业务需求开发中。对于这部分小伙伴来说上班写代码还能赚钱真的是幸福！
怎么成为喜欢编码都那部分人
无论做哪行那业你都喜欢，往往来自从中持续不断都获取成就感。就开发编程而言因为你的一行代码影响到了千千万万的人、因为你的一行代码整个系统更加稳定、因为你的一行代码扛过了所有秒杀等等，这样一行行的代码都是你日积月累学习到的经验。那如果你也想成为这样有成就感的程序员就需要不断的学习，不断的用更多的技能知识把自己编写的代码运用到更核心的系统。
方向不对努力白费
平常你也付出了很多的时间，但就是没有得到多少收益。就像有时候很多小伙伴问我，我是该怎么学一个我没接触过的内容。我的个人经验非常建议，先不要学太多理论性的内容，而是尝试实际操作下，把要学的内容做一些Demo案例出来。这有点像你买了个自行车是先拆了学学怎么个原理，还是先骑几圈呢？哪怕摔了跟头，但那都是必须经历后留下的经验。
同样我也知道很多人看了设计模式收获不大，这主要新人对没有案例或者案例不贴近实际场景没有学习方向导致。太空、太虚、太玄，让人没有抓手！
##原型模式介绍
原型模式主要解决的问题就是创建重复对象，而这部分对象内容本身比较复杂，生成过程可能从库或者RPC接口中获取数据的耗时较长，因此采用克隆的方式节省时间。
其实这种场景经常出现在我们的身边，只不过很少用到自己的开发中，就像：
- 你经常Ctrl+C、Ctrl+V，复制粘贴代码。
- Java多数类中提供的API方法；Object clone()。
- 细胞的有丝分裂。
类似以上的场景并不少，但如果让你去思考平时的代码开发中，有用到这样的设计模式吗？确实不那么容易找到，甚至有时候是忽略了这个设计模式的方式。在没有阅读下文之前，也可以思考下哪些场景可以用到
##案例场景模拟
每个人都经历过考试，从纸制版到上机答题，大大小小也有几百场。而以前坐在教室里答题身边的人都是一套试卷，考试的时候还能偷摸或者别人给发信息抄一抄答案。
但从一部分可以上机考试的内容开始，在保证大家的公平性一样的题目下，开始出现试题混排更有做的好的答案选项也混排。这样大大的增加了抄的成本，也更好的做到了考试的公平性。
但如果这个公平性的考试需求交给你来完成，你会怎么做？
##总结
通过上面对建造者模式的使用，已经可以摸索出一点心得。那就是什么时候会选择这样的设计模式，当：一些基本物料不会变，而其组合经常变化的时候，就可以选择这样的设计模式来构建代码。
此设计模式满足了单一职责原则以及可复用的技术、建造者独立、易扩展、便于控制细节风险。但同时当出现特别多的物料以及很多的组合后，类的不断扩展也会造成难以维护的问题。但这种设计结构模型可以把重复的内容抽象到数据库中，按照需要配置。这样就可以减少代码中大量的重复。
设计模式能带给你的是一些思想，但在平时的开发中怎么样清晰的提炼出符合此思路的建造模块，是比较难的。需要经过一些锻炼和不断承接更多的项目，从而获得这部分经验。有的时候你的代码写的好，往往是倒逼的，复杂的业务频繁的变化，不断的挑战！
#第五章、单例模式「7种单例模式案例」
##前言
5个创建型模式的最后一个
在设计模式中按照不同的处理方式共包含三大类；创建型模式、结构型模式和行为模式，其中创建型模式目前已经介绍了其中的四个；工厂方法模式、抽象工厂模式、生成器模式和原型模式，除此之外还有最后一个单例模式。
掌握了的知识才是自己的
在本次编写的重学 Java 设计模式的编写中尽可能多的用各种场景案例还介绍设计的使用，包括我们已经使用过的场景；各种类型奖品发放、多套Redis缓存集群升级、装修公司报价清单和百份考卷题目与答案乱序，通过这些场景案例的实践感受设计模式的思想。但这些场景都是作者通过经验分离出来的，还并不是读者的知识，所以你如果希望可以融会贯通的掌握那么一定要亲力亲为的操作，事必躬亲的完成。
书不是看的是用的
在这里还是想强调一下学习方法，总有很多小伙伴对学习知识有疑惑，明明看了、看的时候也懂了，但到了实际使用的时候却用不上。或者有时候在想是不要是有更加生动的漫画或者什么对比会好些，当然这些方式可能会加快一个新人对知识的理解速度。但只要你把学习视频当电影看、学习书籍当故事看，就很难掌握这项技术栈。只有你把它用起来，逐字逐句的深挖，一点点的探求，把各项遇到的盲点全部扫清，才能让你真的掌握这项技能。
##单例模式介绍
单例模式可以说是整个设计中最简单的模式之一，而且这种方式即使在没有看设计模式相关资料也会常用在编码开发中。
因为在编程开发中经常会遇到这样一种场景，那就是需要保证一个类只有一个实例哪怕多线程同时访问，并需要提供一个全局访问此实例的点。
综上以及我们平常的开发中，可以总结一条经验，单例模式主要解决的是，一个全局使用的类频繁的创建和消费，从而提升提升整体的代码的性能。
##总结
- 虽然只是一个很平常的单例模式，但在各种的实现上真的可以看到java的基本功的体现，这里包括了；懒汉、饿汉、线程是否安全、静态类、内部类、加锁、串行化等等。
- 在平时的开发中如果可以确保此类是全局可用不需要做懒加载，那么直接创建并给外部调用即可。但如果是很多的类，有些需要在用户触发一定的条件后(游戏关卡)才显示，那么一定要用懒加载。线程的安全上可以按需选择。
- 建议在学习的过程中一定要加以实践，否则很难完完整整的掌握一整套的知识体系。例如案例中的出现的Effective Java一书也非常建议大家阅读。
#第六章、适配器模式「从多个MQ消息体中，抽取指定字段值场景」
##前言
擦屁屁纸80%的面积都是保护手的！
工作到3年左右很大一部分程序员都想提升自己的技术栈，开始尝试去阅读一些源码，例如Spring、Mybaits、Dubbo等，但读着读着发现越来越难懂，一会从这过来一会跑到那去。甚至怀疑自己技术太差，慢慢也就不愿意再触碰这部分知识。
而这主要的原因是一个框架随着时间的发展，它的复杂程度是越来越高的，从最开始只有一个非常核心的点到最后开枝散叶。这就像你自己开发的业务代码或者某个组件一样，最开始的那部分核心代码也许只能占到20%，而其他大部分代码都是为了保证核心流程能正常运行的。所以这也是你读源码费劲的一部分原因。
框架中用到了设计模式吗？
框架中不仅用到设计模式还用了很多，而且有些时候根本不是一个模式的单独使用，而是多种设计模式的综合运用。与大部分小伙伴平时开发的CRUD可就不一样了，如果都是if语句从上到下，也就算得不上什么框架了。就像你到Spring的源码中搜关键字Adapter，就会出现很多实现类，例如；UserCredentialsDataSourceAdapter。而这种设计模式就是我们本文要介绍的适配器模式。
适配器在生活里随处可见
##适配器模式介绍
适配器模式的主要作用就是把原本不兼容的接口，通过适配修改做到统一。使得用户方便使用，就像我们提到的万能充、数据线、MAC笔记本的转换头、出国旅游买个插座等等，他们都是为了适配各种不同的口，做的兼容。。
除了我们生活中出现的各种适配的场景，那么在业务开发中呢？
在业务开发中我们会经常的需要做不同接口的兼容，尤其是中台服务，中台需要把各个业务线的各种类型服务做统一包装，再对外提供接口进行使用。而这在我们平常的开发中也是非常常见的。
##案例场景模拟
随着公司的业务的不断发展，当基础的系统逐步成型以后。业务运营就需要开始做用户的拉新和促活，从而保障DAU的增速以及最终ROI转换。
而这时候就会需要做一些营销系统，大部分常见的都是裂变、拉客，例如；你邀请一个用户开户、或者邀请一个用户下单，那么平台就会给你返利，多邀多得。同时随着拉新的量越来越多开始设置每月下单都会给首单奖励，等等，各种营销场景。
那么这个时候做这样一个系统就会接收各种各样的MQ消息或者接口，如果一个个的去开发，就会耗费很大的成本，同时对于后期的拓展也有一定的难度。此时就会希望有一个系统可以配置一下就把外部的MQ接入进行，这些MQ就像上面提到的可能是一些注册开户消息、商品下单消息等等。
而适配器的思想方式也恰恰可以运用到这里，并且我想强调一下，适配器不只是可以适配接口往往还可以适配一些属性信息。
##总结
- 从上文可以看到不使用适配器模式这些功能同样可以实现，但是使用了适配器模式就可以让代码：干净整洁易于维护、减少大量重复的判断和使用、让代码更加易于维护和拓展。
- 尤其是我们对MQ这样的多种消息体中不同属性同类的值，进行适配再加上代理类，就可以使用简单的配置方式接入对方提供的MQ消息，而不需要大量重复的开发。非常利于拓展。
- 设计模式的学习学习过程可能会在一些章节中涉及到其他设计模式的体现，只不过不会重点讲解，避免喧宾夺主。但在实际的使用中，往往很多设计模式是综合使用的，并不会单一出现。
#第七章、实战桥接模式「多支付渠道(微信、支付宝)与多支付模式(刷脸、指纹)场景」
##前言
为什么你的代码那么多ifelse?
同类的业务、同样的功能，怎么就你能写出来那么多ifelse。很多时候一些刚刚从校园进入企业的萌新，或者一部分从小公司跳槽到大企业的程序员，初次承接业务需求的时候，往往编码还不成熟，经常一杆到底的写需求。初次实现确实很快，但是后期维护和扩展就十分痛苦。因为一段代码的可读性阅读他后期的维护成本也就越高。
设计模式是可以帮助你改善代码
很多时候你写出来的ifelse都是没有考虑使用设计模式优化，就像；同类服务的不同接口适配包装、同类物料不同组合的建造、多种奖品组合的营销工厂等等。它们都可以让你代码中原本使用if判断的地方，变成一组组类和面向对象的实现过程。
怎么把设计模式和实际开发结合起来
多从实际场景思考，只找到代码优化的最佳点，不要可以想着设计模式的使用。就像你最开始看设计模式适合，因为没有真实的场景模拟案例，都是一些画圆形、方形，对新人或者理解能力还不到的伙伴来说很不友好。所以即使学了半天 ，但实际使用还是摸不着头脑。
##桥接模式介绍
桥接模式的主要作用就是通过将抽象部分与实现部分分离，把多种可匹配的使用进行组合。说白了核心实现也就是在A类中含有B类接口，通过构造函数传递B类的实现，这个B类就是设计的桥。
那么这样的桥接模式，在我们平常的开发中有哪些场景
JDBC多种驱动程序的实现、同品牌类型的台式机和笔记本平板、业务实现中的多类接口同组过滤服务等。这些场景都比较适合使用桥接模式进行实现，因为在一些组合中如果有如果每一个类都实现不同的服务可能会出现笛卡尔积，而使用桥接模式就可以非常简单。
##案例场景模拟
随着市场的竞争在支付服务行业出现了微信和支付宝还包括一些其他支付服务，但是对于商家来说并不希望改变用户习惯。就像如果我的地摊只能使用微信或者只能使用支付宝付款，那么就会让我顾客伤心，鸡蛋灌饼也卖不动了。
在这个时候就出现了第三方平台，把市面上综合占据市场90%以上的支付服务都集中到自己平台中，再把这样的平台提供给店铺、超市、地摊使用，同时支持人脸、扫描、密码多种方式。
我们这个案例就模拟一个这样的第三方平台来承接各个支付能力，同时使用自家的人脸让用户支付起来更加容易。那么这里就出现了多支付与多模式的融合使用，如果给每一个支付都实现一次不同的模式，即使是继承类也需要开发好多。而且随着后面接入了更多的支付服务或者支付方式，就会呈爆炸似的扩展。
所以你现在可以思考一下这样的场景该如何实现？
##总结
- 通过模拟微信与支付宝两个支付渠道在不同的支付模式下，刷脸、指纹、密码，的组合从而体现了桥接模式的在这类场景中的合理运用。简化了代码的开发，给后续的需求迭代增加了很好的扩展性。
- 从桥接模式的实现形式来看满足了单一职责和开闭原则，让每一部分内容都很清晰易于维护和拓展，但如果我们是实现的高内聚的代码，那么就会很复杂。所以在选择重构代码的时候，需要考虑好整体的设计，否则选不到合理的设计模式，将会让代码变得难以开发。
- 任何一种设计模式的选择和使用都应该遵顼符合场景为主，不要刻意使用。而且统一场景因为业务的复杂从而可能需要使用到多种设计模式的组合，才能将代码设计的更加合理。但这种经验需要从实际的项目中学习经验，并提不断的运用。
#第八章、实战组合模式「营销差异化人群发券，决策树引擎搭建场景」
##前言
小朋友才做选择题，成年人我都要头几年只要群里一问我该学哪个开发语言，哪个语言最好。群里肯定聊的特别火热，有人支持PHP、有人喊号Java、也有C++和C#。但这几年开始好像大家并不会真的刀枪棍棒、斧钺钩叉般讨论了，大多数时候都是开玩笑的闹一闹。于此同时在整体的互联网开发中很多时候是一些开发语言公用的，共同打造整体的生态圈。而大家选择的方式也是更偏向于不同领域下选择适合的架构，而不是一味地追求某个语言。这可以给很多初学编程的新人一些提议，不要刻意的觉得某个语言好，某个语言不好，只是在适合的场景下选择最需要的。而你要选择的那个语言可以参考招聘网站的需求量和薪资水平决定。
编程开发不是炫技总会有人喜欢在整体的项目开发中用上点新特性，把自己新学的知识实践试试。不能说这样就是不好，甚至可以说这是一部分很热爱学习的人，喜欢创新，喜欢实践。但编程除了用上新特性外，还需要考虑整体的扩展性、可读性、可维护、易扩展等方面的考虑。就像你家里雇佣了一伙装修师傅，有那么一个小工喜欢炫技搞花活，在家的淋浴下🚿安装了马桶🚽。
即使是写CRUD也应该有设计模式往往很多大需求都是通过增删改查堆出来的，今天要一个需求if一下，明天加个内容else扩展一下。日积月累需求也就越来越大，扩展和维护的成本也就越来越高。往往大部分研发是不具备产品思维和整体业务需求导向的，总以为写好代码完成功能即可。但这样的不考虑扩展性的实现，很难让后续的需求都快速迭代，久而久之就会被陷入恶性循环，每天都有bug要改。
##组合模式介绍
从上图可以看到这有点像螺丝🔩和螺母，通过一堆的链接组织出一棵结构树。而这种通过把相似对象(也可以称作是方法)组合成一组可被调用的结构树对象的设计思路叫做组合模式。
这种设计方式可以让你的服务组节点进行自由组合对外提供服务，例如你有三个原子校验功能(A：身份证、B：银行卡、C：手机号)服务并对外提供调用使用。有些调用方需要使用AB组合，有些调用方需要使用到CBA组合，还有一些可能只使用三者中的一个。那么这个时候你就可以使用组合模式进行构建服务，对于不同类型的调用方配置不同的组织关系树，而这个树结构你可以配置到数据库中也可以不断的通过图形界面来控制树结构。
所以不同的设计模式用在恰当好处的场景可以让代码逻辑非常清晰并易于扩展，同时也可以减少团队新增人员对项目的学习成本
##案例场景模拟
以上是一个非常简化版的营销规则决策树，根据性别、年龄来发放不同类型的优惠券，来刺激消费起到精准用户促活的目的。
虽然一部分小伙伴可能并没有开发过营销场景，但你可能时时刻刻的被营销着。比如你去经常浏览男性喜欢的机械键盘、笔记本电脑、汽车装饰等等，那么久给你推荐此类的优惠券刺激你消费。那么如果你购物不多，或者钱不在自己手里。那么你是否打过车，有一段时间经常有小伙伴喊，为什么同样的距离他就10元，我就15元呢？其实这些都是被营销的案例，一般对于不常使用软件的小伙伴，经常会进行稍微大力度的促活，增加用户粘性。
那么在这里我们就模拟一个类似的决策场景，体现出组合模式在其中起到的重要性。另外，组合模式不只是可以运用于规则决策树，还可以做服务包装将不同的接口进行组合配置，对外提供服务能力，减少开发成本。
##总结
从以上的决策树场景来看，组合模式的主要解决的是一系列简单逻辑节点或者扩展的复杂逻辑节点在不同结构的组织下，对于外部的调用是仍然可以非常简单的。
这部分设计模式保证了开闭原则，无需更改模型结构你就可以提供新的逻辑节点的使用并配合组织出新的关系树。但如果是一些功能差异化非常大的接口进行包装就会变得比较困难，但也不是不能很好的处理，只不过需要做一些适配和特定化的开发。
很多时候因为你的极致追求和稍有倔强的工匠精神，即使在面对同样的业务需求，你能完成出最好的代码结构和最易于扩展的技术架构。不要被远不能给你指导提升能力的影响到放弃自己的追求！
#第九章、实战装饰器模式「SSO单点登录功能扩展，增加拦截用户访问方法范围场景」
##前言
对于代码你有编程感觉吗
很多人写代码往往是没有编程感觉的，也就是除了可以把功能按照固定的流程编写出流水式的代码外，很难去思考整套功能服务的扩展性和可维护性。尤其是在一些较大型的功能搭建上，比较缺失一些驾驭能力，从而导致最终的代码相对来说不能做到尽善尽美。
江洋大盗与江洋大偷
两个本想描述一样的意思的词，只因一字只差就让人觉得一个是好牛，一个好搞笑。往往我们去开发编程写代码时也经常将一些不恰当的用法用于业务需求实现中，但却不能意识到。一方面是由于编码不多缺少较大型项目的实践，另一方面是不思进取的总在以完成需求为目标缺少精益求精的工匠精神。
书从来不是看的而是用的
在这个学习资料几乎爆炸的时代，甚至你可以轻易就获取几个T的视频，小手轻轻一点就收藏一堆文章，但却很少去看。学习的过程从不只是简单的看一遍就可以，对于一些实操性的技术书籍，如果真的希望学习到知识，那么一定是把这本书用起来而绝对不是看起来。
##装饰器模式介绍
初看上图感觉装饰器模式有点像俄罗斯套娃、某众汽车🚕，而装饰器的核心就是再不改原有类的基础上给类新增功能。不改变原有类，可能有的小伙伴会想到继承、AOP切面，当然这些方式都可以实现，但是使用装饰器模式会是另外一种思路更为灵活，可以避免继承导致的子类过多，也可以避免AOP带来的复杂性。
你熟悉的场景很多用到装饰器模式
new BufferedReader(new FileReader(""));，这段代码你是否熟悉，相信学习java开发到字节流、字符流、文件流的内容时都见到了这样的代码，一层嵌套一层，一层嵌套一层，字节流转字符流等等，而这样方式的使用就是装饰器模式的一种体现。
##案例场景模拟
在本案例中我们模拟一个单点登录功能扩充的场景
一般在业务开发的初期，往往内部的ERP使用只需要判断账户验证即可，验证通过后即可访问ERP的所有资源。但随着业务的不断发展，团队里开始出现专门的运营人员、营销人员、数据人员，每个人员对于ERP的使用需求不同，有些需要创建活动，有些只是查看数据。同时为了保证数据的安全性，不会让每个用户都有最高的权限。
那么以往使用的SSO是一个组件化通用的服务，不能在里面添加需要的用户访问验证功能。这个时候我们就可以使用装饰器模式，扩充原有的单点登录服务。但同时也保证原有功能不受破坏，可以继续使用。
##总结
使用装饰器模式满足单一职责原则，你可以在自己的装饰类中完成功能逻辑的扩展，而不影响主类，同时可以按需在运行时添加和删除这部分逻辑。另外装饰器模式与继承父类重写方法，在某些时候需要按需选择，并不一定某一个就是最好。
装饰器实现的重点是对抽象类继承接口方式的使用，同时设定被继承的接口可以通过构造函数传递其实现类，由此增加扩展性并重写方法里可以实现此部分父类实现的功能。
就像夏天热你穿短裤，冬天冷你穿棉裤，雨天挨浇你穿雨衣一样，你的根本本身没有被改变，而你的需求却被不同的装饰而实现。生活中往往比比皆是设计，当你可以融合这部分活灵活现的例子到代码实现中，往往会创造出更加优雅的实现方式。
#第十章、实战外观模式「基于SpringBoot开发门面模式中间件，统一控制接口白名单场景」
##前言
你感受到的容易，一定有人为你承担不容易
这句话更像是描述生活的，许许多多的磕磕绊绊总有人为你提供躲雨的屋檐和避风的港湾。其实编程开发的团队中也一样有人只负责CRUD中的简单调用，去使用团队中高级程序员开发出来的核心服务和接口。这样的编程开发对于初期刚进入程序员行业的小伙伴来说锻炼锻炼还是不错的，但随着开发的日子越来越久一直做这样的事情就很难得到成长，也想努力的去做一些更有难度的承担，以此来增强个人的技术能力。
没有最好的编程语言，语言只是工具
刀枪棍棒、斧钺钩叉、包子油条、盒子麻花，是语言。五郎八卦棍、十二路弹腿、洪家铁线拳，是设计。记得叶问里有一句台词是：金山找：今天我北方拳术，输给你南方拳术了。叶问：你错了，不是南北拳的问题，是你的问题。所以当你编程开发写的久了，就不会再特别在意用的语言，而是为目标服务，用最好的设计能力也就是编程的智慧做出做最完美的服务。这也就是编程人员的价值所在！
设计与反设计以及过渡设计
设计模式是解决程序中不合理、不易于扩展、不易于维护的问题，也是干掉大部分ifelse的利器，在我们常用的框架中基本都会用到大量的设计模式来构建组件，这样也能方便框架的升级和功能的扩展。但！如果不能合理的设计以及乱用设计模式，会导致整个编程变得更加复杂难维护，也就是我们常说的；反设计、过渡设计。而这部分设计能力也是从实践的项目中获取的经验，不断的改造优化摸索出的最合理的方式，应对当前的服务体量。
##外观模式介绍
外观模式也叫门面模式，主要解决的是降低调用方的使用接口的复杂逻辑组合。这样调用方与实际的接口提供方提供方提供了一个中间层，用于包装逻辑提供API接口。有些时候外观模式也被用在中间件层，对服务中的通用性复杂逻辑进行中间件层包装，让使用方可以只关心业务开发。
那么这样的模式在我们的所见产品功能中也经常遇到，就像几年前我们注册一个网站时候往往要添加很多信息，包括；姓名、昵称、手机号、QQ、邮箱、住址、单身等等，但现在注册成为一个网站的用户只需要一步即可，无论是手机号还是微信也都提供了这样的登录服务。而对于服务端应用开发来说以前是提供了一个整套的接口，现在注册的时候并没有这些信息，那么服务端就需要进行接口包装，在前端调用注册的时候服务端获取相应的用户信息(从各个渠道)，如果获取不到会让用户后续进行补全(营销补全信息给奖励)，以此来拉动用户的注册量和活跃度。
##案例场景模拟
在本案例中我们模拟一个将所有服务接口添加白名单的场景
在项目不断壮大发展的路上，每一次发版上线都需要进行测试，而这部分测试验证一般会进行白名单开量或者切量的方式进行验证。那么如果在每一个接口中都添加这样的逻辑，就会非常麻烦且不易维护。另外这是一类具备通用逻辑的共性需求，非常适合开发成组件，以此来治理服务，让研发人员更多的关心业务功能开发。
一般情况下对于外观模式的使用通常是用在复杂或多个接口进行包装统一对外提供服务上，此种使用方式也相对简单在我们平常的业务开发中也是最常用的。你可能经常听到把这两个接口包装一下，但在本例子中我们把这种设计思路放到中间件层，让服务变得可以统一控制。
##总结
- 以上我们通过中间件的方式实现外观模式，这样的设计可以很好的增强代码的隔离性，以及复用性，不仅使用上非常灵活也降低了每一个系统都开发这样的服务带来的风险。
- 可能目前你看这只是非常简单的白名单控制，是否需要这样的处理。但往往一个小小的开始会影响着后续无限的扩展，实际的业务开发往往也要复杂的很多，不可能如此简单。因而使用设计模式来让代码结构更加干净整洁。
- 很多时候不是设计模式没有用，而是自己编程开发经验不足导致即使学了设计模式也很难驾驭。毕竟这些知识都是经过一些实际操作提炼出来的精华，但如果你可以按照本系列文章中的案例方式进行学习实操，还是可以增强这部分设计能力的。
#第十一章、实战享元模式「基于Redis秒杀，提供活动与库存信息查询场景」
##前言
程序员👨💻的上下文是什么？
很多时候一大部分编程开发的人员都只是关注于功能的实现，只要自己把这部分需求写完就可以了，有点像被动的交作业。这样的问题一方面是由于很多新人还不了解程序员的职业发展，还有一部分是对于编程开发只是工作并非兴趣。但在程序员的发展来看，如果不能很好的处理上文(产品)，下文(测试)，在这样不能很好的了解业务和产品发展，也不能编写出很有体系结构的代码，日久天长，1到3年、3到5年，就很难跨越一个个技术成长的分水岭。
拥有接受和学习新知识的能力
你是否有感受过小时候在什么都还不会的时候接受知识的能力很强，但随着我们开始长大后，慢慢学习能力、处事方式、性格品行，往往会固定。一方面是形成了各自的性格特征，一方面是圈子已经固定。但也正因为这样的故步，而很少愿意听取别人的意见，就像即使看到了一整片内容，在视觉盲区下也会过掉到80%，就在眼前也看不见，也因此导致了能力不再有较大的提升。
编程能力怎样会成长的最快
工作内容往往有些像在工厂🏭拧螺丝，大部分内容是重复的，也可以想象过去的一年你有过多少创新和学习了新的技能。那么这时候一般为了多学些内容会买一些技术书籍，但！技术类书籍和其他书籍不同，只要不去用看了也就只是轻描淡写，很难接纳和理解。就像设计模式，虽然可能看了几遍，但是在实际编码中仍然很少会用，大部分原因还是没有认认真真的跟着实操。事必躬亲才是学习编程的最好是方式。
##享元模式介绍
享元模式，主要在于共享通用对象，减少内存的使用，提升系统的访问效率。而这部分共享对象通常比较耗费内存或者需要查询大量接口或者使用数据库资源，因此统一抽离作为共享对象使用。
另外享元模式可以分为在服务端和客户端，一般互联网H5和Web场景下大部分数据都需要服务端进行处理，比如数据库连接池的使用、多线程线程池的使用，除了这些功能外，还有些需要服务端进行包装后的处理下发给客户端，因为服务端需要做享元处理。但在一些游戏场景下，很多都是客户端需要进行渲染地图效果，比如；树木、花草、鱼虫，通过设置不同元素描述使用享元公用对象，减少内存的占用，让客户端的游戏更加流畅。
在享元模型的实现中需要使用到享元工厂来进行管理这部分独立的对象和共享的对象，避免出现线程安全的问题
##案例场景模拟
在这个案例中我们模拟在商品秒杀场景下使用享元模式查询优化
你是否经历过一个商品下单的项目从最初的日均十几单到一个月后每个时段秒杀量破十万的项目。一般在最初如果没有经验的情况下可能会使用数据库行级锁的方式下保证商品库存的扣减操作，但是随着业务的快速发展秒杀的用户越来越多，这个时候数据库已经扛不住了，一般都会使用redis的分布式锁来控制商品库存。
同时在查询的时候也不需要每一次对不同的活动查询都从库中获取，因为这里除了库存以外其他的活动商品信息都是固定不变的，以此这里一般大家会缓存到内存中。
这里我们模拟使用享元模式工厂结构，提供活动商品的查询。活动商品相当于不变的信息，而库存部分属于变化的信息
##总结
- 关于享元模式的设计可以着重学习享元工厂的设计，在一些有大量重复对象可复用的场景下，使用此场景在服务端减少接口的调用，在客户端减少内存的占用。是这个设计模式的主要应用方式。
- 另外通过map结构的使用方式也可以看到，使用一个固定id来存放和获取对象，是非常关键的点。而且不只是在享元模式中使用，一些其他工厂模式、适配器模式、组合模式中都可以通过map结构存放服务供外部获取，减少ifelse的判断使用。
- 当然除了这种设计的减少内存的使用优点外，也有它带来的缺点，在一些复杂的业务处理场景，很不容易区分出内部和外部状态，就像我们活动信息部分与库存变化部分。如果不能很好的拆分，就会把享元工厂设计的非常混乱，难以维护。
#第十二章、实战代理模式「模拟mybatis-spring中定义DAO接口，使用代理类方式操作数据库原理实现场景」
##前言
难以跨越的瓶颈期，把你拿捏滴死死的！
编程开发学习过程中遇到的瓶颈期，往往是由于看不到前进的方向。这个时候你特别希望能有人告诉你，你还欠缺些什么朝着哪个方向努力。而导致这一问题的主要原因是由于日常的业务开发太过于复制过去，日复一日的重复。没有太多的挑战，也没参与过较大体量的业务场景，除了这些开发场景因素外，还有缺少组内的技术氛围和技术分享，没有人做传播和布道者，也缺少自己对各项技术学习的热情，从而导致一直游荡在瓶颈之下，难以提升。
小公司与大公司，选择哪个？
刨除掉薪资以外你会选择什么，是不有人建议小公司，因为可以接触到各个环境，也有人建议大公司，因为正规体量大可以学习到更多。有些时候你的技术成长缓慢也是因为你的不同选择而导致的，小公司确实要接触各个环境，但往往如果你所做的业务体量不高，那么你会用到的技术栈就会相对较少，同时也会技术栈研究的深度也会较浅。大公司中确实有时候你不需要去关心一个集群的部署和维护、一个中间件的开发、全套服务监控等等，但如果你愿意了解这些技术在内部都是公开的，你会拥有无限的技术营养可以补充。而这最主要的是提升视野和事业。
除了业务中的CRUD开发，有些技术你真的很难接触到！
可能很多小伙伴认为技术开发就是承接下产品需求，写写CRUD，不会的百度一下，就完事了，总觉得别人问的东西像再造火箭一样。但在高体量、高并发的业务场景下，每一次的压测优化，性能提升，都像在研究一道数学题一样，反复的锤炼，压榨性能。不断的深究，找到最合适的设计。除了这些优化提升外，还有那么广阔的技术体系栈，都可能因为你只是注重CRUD而被忽略；字节码编程、领域驱动设计架构、代理模式中间件开发、JVM虚拟机实现原理等等。
##代理模式介绍
代理模式有点像老大和小弟，也有点像分销商。主要解决的是问题是为某些资源的访问、对象的类的易用操作上提供方便使用的代理服务。而这种设计思想的模式经常会出现在我们的系统中，或者你用到过的组件中，它们都提供给你一种非常简单易用的方式控制原本你需要编写很多代码的进行使用的服务类。
类似这样的场景可以想到；
- 你的数据库访问层面经常会提供一个较为基础的应用，以此来减少应用服务扩容时不至于数据库连接数暴增。
- 使用过的一些中间件例如；RPC框架，在拿到jar包对接口的描述后，中间件会在服务启动的时候生成对应的代理类，当调用接口的时候，实际是通过代理类发出的socket信息进行通过。
- 另外像我们常用的MyBatis，基本是定义接口但是不需要写实现类，就可以对xml或者自定义注解里的sql语句进行增删改查操作。
##案例场景模拟
在本案例中我们模拟实现mybatis-spring中代理类生成部分
对于Mybatis的使用中只需要定义接口不需要写实现类就可以完成增删改查操作，有疑问的小伙伴，在本章节中就可以学习到这部分知识。解析下来我们会通过实现一个这样的代理类交给spring管理的核心过程，来讲述代理类模式。
这样的案例场景在实际的业务开发中其实不多，因为这是将这种思想运用在中间件开发上，而很多小伙伴经常是做业务开发，所以对Spring的bean定义以及注册和对代理以及反射调用的知识了解的相对较少。但可以通过本章节作为一个入门学习，逐步了解。
##总结
- 关于这部分代理模式的讲解我们采用了开发一个关于mybatis-spring中间件中部分核心功能来体现代理模式的强大之处，所以涉及到了一些关于代理类的创建以及spring中bean的注册这些知识点，可能在平常的业务开发中都是很少用到的，但是在中间件开发中确实非常常见的操作。
- 代理模式除了开发中间件外还可以是对服务的包装，物联网组件等等，让复杂的各项服务变为轻量级调用、缓存使用。你可以理解为你家里的电灯开关，我们不能操作220v电线的人肉连接，但是可以使用开关，避免触电。
- 代理模式的设计方式可以让代码更加整洁、干净易于维护，虽然在这部分开发中额外增加了很多类也包括了自己处理bean的注册等，但是这样的中间件复用性极高也更加智能，可以非常方便的扩展到各个服务应用中。
#第十三章、实战责任链模式「模拟618电商大促期间，项目上线流程多级负责人审批场景」
##前言
场地和场景的重要性
射击🏹需要去靶场学习、滑雪🏂需要去雪场体验、开车🚗需要能上路实践，而编程开发除了能完成产品的功能流程，还需要保证系统的可靠性能。就像你能听到的一些系统监控指标；QPS、TPS、TP99、TP999、可用率、响应时长等等，而这些指标的总和评估就是一个系统的健康度。但如果你几乎没有听到这样的技术术语，也没接触过类似高并发场景，那么就很像驾驶证的科目1考了100分，但不能上路。没有这样的技术场景给你训练，让你不断的体会系统的脾气秉性，即便你有再多的想法都没法实现。所以，如果真的想学习一定要去一个有实操的场景，下水试试才能学会狗刨。
你的视觉盲区有多大
同样一本书、同样一条路、同样一座城，你真的以为生活有选择吗？有时候很多选项都是摆设，给你多少次机会你都选的一模一样。这不是你选不选而是你的认知范围决定了你下一秒做的事情，另外的一个下一秒又决定了再下一个下一秒。就像管中窥豹一样，20%的面积在你视觉里都是黑色的，甚至就总是忽略看不到，而这看不到的20%就是生命中的时运！但，人可以学习，可以成长，可以脱胎换骨，可以努力付出，通过一次次的蜕变而看到剩下的20%！
没有设计图纸你敢盖楼吗
编程开发中最好的什么，是设计。运用架构思维、经验心得、才华灵感，构建出最佳的系统。真正的研发会把自己写的代码当做作品来欣赏，你说这是一份工作，但在这样的人眼里这可不是一份工作，而是一份工匠精神。就像可能时而你也会为自己因为一个niubility的设计而豪迈万丈，为能上线一个扛得住每秒200万访问量的系统会精神焕发。这样的自豪感就是一次次垒砖一样垫高脚底，不断的把你的视野提高，让你能看到上层设计也能知晓根基建设。可以把控全局，也可以治理细节。这一份份知识的沉淀，来帮助你绘制出一张系统架构蓝图
##责任链模式介绍
击鼓传雷，看上图你是否想起周星驰有一个电影，大家坐在海边围成一个圈，拿着一个点燃的炸弹，互相传递。
责任链模式的核心是解决一组服务中的先后执行处理关系，就有点像你没钱花了，需要家庭财务支出审批，10块钱以下找闺女审批，100块钱先闺女审批在媳妇审批。你可以理解想象成当你要跳槽的时候被安排的明明白白的被各个领导签字放行
##案例场景模拟
在本案例中我们模拟在618大促期间的业务系统上线审批流程场景
像是这些一线电商类的互联网公司，阿里、京东、拼多多等，在618期间都会做一些运营活动场景以及提供的扩容备战，就像过年期间百度的红包一样。但是所有开发的这些系统都需要陆续的上线，因为临近618有时候也有一些紧急的调整的需要上线，但为了保障线上系统的稳定性是尽可能的减少上线的，也会相应的增强审批力度。就像一级响应、二级响应一样。
而这审批的过程在随着特定时间点会增加不同级别的负责人加入，每个人就像责任链模式中的每一个核心点。对于研发小伙伴并不需要关心具体的审批流程处理细节，只需要知道这个上线更严格，级别也更高，但对于研发人员来说同样是点击相同的提审按钮，等待审核。
接下来我们就模拟这样一个业务诉求场景，使用责任链的设计模式来实现此功能。
##总结
- 从上面代码从if语句重构到使用责任链模式开发可以看到，我们的代码结构变得清晰干净了，也解决了大量if语句的使用。并不是if语句不好，只不过if语句并不适合做系统流程设计，但是在做判断和行为逻辑处理中还是非常可以使用的。
- 在我们前面学习结构性模式中讲到过组合模式，它像是一颗组合树一样，我们搭建出一个流程决策树。其实这样的模式也是可以和责任链模型进行组合扩展使用，而这部分的重点在于如何关联链路的关联，最终的执行都是在执行在中间的关系链。
- 责任链模式很好的处理单一职责和开闭原则，简单了耦合也使对象关系更加清晰，而且外部的调用方并不需要关心责任链是如何进行处理的*(以上程序中可以把责任链的组合进行包装，在提供给外部使用)*。但除了这些优点外也需要是适当的场景才进行使用，避免造成性能以及编排混乱调试测试疏漏问题。
#第十四章、实战命令模式「模拟高档餐厅八大菜系，小二点单厨师烹饪场景」
##前言
持之以恒的重要性
初学编程往往都很懵，几乎在学习的过程中会遇到各种各样的问题，哪怕别人那运行好好的代码，但你照着写完就报错。但好在你坚持住了，否则你可能看不到这篇文章。时间和成长就是相互关联着，你在哪条路上坚持走的久，就能看见那条的终点有多美，但如果你浪费了一次又一次努力的机会，那么你也会同样错过很多机遇，因为你的路换了。坚持学习、努力成长，持以恒的付出一定会有所收获。
学习方法的重要性
不会学习往往会耽误很多时间，又没有可观的收成。但不会学习有时候是因为懒造成的，尤其是学习视频、书籍资料、技术文档等，如果只是看了却不是实际操作验证，那么真的很难把别人的知识让自己吸收，即使是当时感觉会了也很快就会忘记。时而也经常会有人找到你说；“这个我不知道，你先告诉我，过后我就学。”但过后你学了吗？
你愿意为一个知识盲区付出多长时间
你心里时而会蹦出这样的词吗；太难了我不会、找个人帮一下吧、放弃了放弃了，其实谁都可能遇到很不好解决的问题，也是可以去问去咨询的。但，如果在这之前你没有在自己的大脑中反复的寻找答案，那么你的大脑中就不会形成一个凸点的知识树，缺少了这个学习过程也就缺少了查阅各种资料给自己大脑填充知识的机会，哪怕是问到了答案最终也会因时间流逝而忘记。
##命令模式介绍
命令模式在我们通常的互联网开发中相对来说用的比较少，但这样的模式在我们的日常中却经常使用到，那就是Ctrl+C、Ctrl+V。当然如果你开发过一些桌面应用，也会感受到这样设计模式的应用场景。从这样的模式感受上，可以想到这是把逻辑实现与操作请求进行分离，降低耦合方便扩展。
命令模式是行为模式中的一种，以数据驱动的方式将命令对象，可以使用构造函数的方式传递给调用者。调用者再提供相应的实现为命令执行提供操作方法。可能会感觉这部分有一些饶，可以通过对代码的实现进行理解，在通过实操来熟练。
在这个设计模式的实现过程中有如下几个比较重要的点；
- 抽象命令类；声明执行命令的接口和方法
- 具体的命令实现类；接口类的具体实现，可以是一组相似的行为逻辑
- 实现者；也就是为命令做实现的具体实现类
- 调用者；处理命令、实现的具体操作者，负责对外提供命令服务
##案例场景模拟
在这个案例中我们模拟在餐厅中点餐交给厨师👨🍳烹饪的场景
命令场景的核心的逻辑是调用方与不需要去关心具体的逻辑实现，在这个场景中也就是点餐人员只需要把需要点的各种菜系交个小二就可以，小二再把各项菜品交给各个厨师进行烹饪。也就是点餐人员不需要跟各个厨师交流，只需要在统一的环境里下达命令就可以。
在这个场景中可以看到有不同的菜品；山东（鲁菜）、四川（川菜）、江苏（苏菜）、广东（粤菜）、福建（闽菜）、浙江（浙菜）、湖南（湘菜），每种菜品都会有不同的厨师👩🍳进行烹饪。而客户并不会去关心具体是谁烹饪，厨师也不会去关心谁点的餐。客户只关心早点上菜，厨师只关心还有多少个菜要做。而这中间的衔接的过程，由小二完成。
那么在这样的一个模拟场景下，可以先思考🤔哪部分是命令模式的拆解，哪部分是命令的调用者以及命令的实现逻辑。
##总结
- 从以上的内容和例子可以感受到，命令模式的使用场景需要分为三个比较大的块；命令、实现、调用者，而这三块内容的拆分也是选择适合场景的关键因素，经过这样的拆分可以让逻辑具备单一职责的性质，便于扩展。
- 通过这样的实现方式与if语句相比，降低了耦合性也方便其他的命令和实现的扩展。但同时这样的设计模式也带来了一点问题，就是在各种命令与实现的组合下，会扩展出很多的实现类，需要进行管理。
- 设计模式的学习一定要勤加练习，哪怕最开始是模仿实现也是可以的，多次的练习后再去找到一些可以优化的场景，并逐步运用到自己的开发中。提升自己对代码的设计感觉，让代码结构更加清晰易扩展。
#第十五章、实战迭代器模式「模拟公司组织架构树结构关系，深度迭代遍历人员信息输出场景」
##前言
相信相信的力量！
从懵懂的少年，到拿起键盘，可以写一个HelloWorld。多数人在这并不会感觉有多难，也不会认为做不出来。因为这样的例子，有老师的指导、有书本的例子、有前人的经验。但随着你的开发时间越来越长，要解决更复杂的问题或者技术创新，因此在网上搜了几天几夜都没有答案，这个时候是否想过放弃，还是一直坚持不断的尝试一点点完成自己心里要的结果。往往这种没有前车之鉴需要自己解决问题的时候，可能真的会折磨到要崩溃，但你要愿意执着、愿意倔强，愿意选择相信相信的力量，就一定能解决。哪怕解决不了，也可以在这条路上摸索出其他更多的收获，为后续前进的道路填充好垫脚石。
时间紧是写垃圾代码的理由？
拧螺丝？Ctrl+C、Ctrl+V？贴膏药一样写代码？没有办法，没有时间，往往真的是借口，胸中没有笔墨，才只能凑合。难道一定是好好写代码就浪费时间，拼凑CRUD就快吗，根本不可能的。因为不会，没有实操过，很少架构出全场景的设计，才很难写出优良的代码。多增强自身的编码(武术)修为，在各种编码场景中让自己变得老练，才好应对紧急情况下的需求开发和人员安排。就像韩信一样有谋有略，才能执掌百万雄兵。
不要只是做个工具人！
因为日常的编写简单业务需求，导致自己像个工具人一样，日久天长的也就很少去深入学习更多技术栈。看见有工具、有组件、有框架，拿来就用用，反正没什么体量也不会出什么问题。但如果你想要更多的收入，哪怕是重复的造轮子，你也要去尝试造一个，就算不用到生产，自己玩玩总可以吧。有些事情只有自己经历过，才能有最深的感触，参与过实践过，才好总结点评学习。
##迭代器模式介绍
迭代器模式，常见的就是我们日常使用的iterator遍历。虽然这个设计模式在我们的实际业务开发中的场景并不多，但却几乎每天都要使用jdk为我们提供的list集合遍历。另外增强的for循环虽然是循环输出数据，但是他不是迭代器模式。迭代器模式的特点是实现Iterable接口，通过next的方式获取集合元素，同时具备对元素的删除等操作。而增强的for循环是不可以的。
这种设计模式的优点是可以让我们以相同的方式，遍历不同的数据结构元素，这些数据结构包括；数组、链表、树等，而用户在使用遍历的时候并不需要去关心每一种数据结构的遍历处理逻辑，从让使用变得统一易用。
##案例场景模拟
在本案例中我们模拟迭代遍历输出公司中树形结构的组织架构关系中雇员列表
大部分公司的组织架构都是金字塔结构，也就这种树形结构，分为一级、二级、三级等部门，每个组织部门由雇员填充，最终体现出一个整体的树形组织架构关系。
一般我们常用的遍历就是jdk默认提供的方法，对list集合遍历。但是对于这样的偏业务特性较大的树形结构，如果需要使用到遍历，那么就可以自己来实现。接下来我们会把这个组织层次关系通过树形数据结构来实现，并完成迭代器功能
##总结
- 迭代器的设计模式从以上的功能实现可以看到，满足了单一职责和开闭原则，外界的调用方也不需要知道任何一个不同的数据结构在使用上的遍历差异。可以非常方便的扩展，也让整个遍历变得更加干净整洁。
- 但从结构的实现上可以看到，迭代器模式的实现过程相对来说是比较复杂的，类的实现上也扩增了需要外部定义的类，使得遍历与原数据结构分开。虽然这是比较麻烦的，但可以看到在使用java的jdk时候，迭代器的模式还是很好用的，可以非常方便扩展和升级。
- 以上的设计模式场景实现过程可能对新人有一些不好理解点，包括；迭代器三个接口的定义、树形结构的数据关系、树结构深度遍历思路。这些都需要反复实现练习才能深入的理解，事必躬亲，亲历亲为，才能让自己掌握这些知识。
#第十六章、实战中介者模式「按照Mybatis原理手写ORM框架，给JDBC方式操作数据库增加中介者场景」
##前言
同龄人的差距是从什么时候拉开的
同样的幼儿园、同样的小学、一样的书本、一样的课堂，有人学习好、有人学习差。不只是上学，几乎人生处处都是赛道，发令枪响起的时刻，也就把人生的差距拉开。编程开发这条路也是很长很宽，有人跑得快有人跑得慢。那么你是否想起过，这一点点的差距到遥不可及的距离，是从哪一天开始的。摸摸肚子的肉，看看远处的路，别人讲的是故事，你想起的都是事故。
思想没有产品高才写出一片的ifelse
当你承接一个需求的时候，比如；交易、订单、营销、保险等各类场景。如果你不熟悉这个场景下的业务模式，以及将来的拓展方向，那么很难设计出良好可扩展的系统。再加上产品功能初建，说老板要的急，尽快上线。作为程序员的你更没有时间思考，整体一看现在的需求也不难，直接上手开干(一个方法两个if语句)，这样确实满足了当前需求。但老板的想法多呀，产品也跟着变化快，到你这就是改改改，加加加。当然你也不客气，回首掏就是1024个if语句！
日积月累的技术沉淀是为了厚积薄发
粗略的估算过，如果从上大学开始每天写200行，一个月是6000行，一年算10个月话，就是6万行，第三年出去实习的是时候就有20万行的代码量。如果你能做到这一点，找工作难？有时候很多事情就是靠时间积累出来的，想走捷径有时候真的没有。你的技术水平、你的业务能力、你身上的肉，都是一点点积累下来的，不要浪费看似很短的时间，一年年坚持下来，留下印刻青春的痕迹，多给自己武装上一些能力。
##中介者模式介绍
中介者模式要解决的就是复杂功能应用之间的重复调用，在这中间添加一层中介者包装服务，对外提供简单、通用、易扩展的服务能力。
这样的设计模式几乎在我们日常生活和实际业务开发中都会见到，例如；飞机🛬降落有小姐姐在塔台喊话、无论哪个方向来的候车都从站台上下、公司的系统中有一个中台专门为你包装所有接口和提供统一的服务等等，这些都运用了中介者模式。除此之外，你用到的一些中间件，他们包装了底层多种数据库的差异化，提供非常简单的方式进行使用。
##案例场景模拟
在本案例中我们通过模仿Mybatis手写ORM框架，通过这样操作数据库学习中介者运用场景
除了这样的中间件层使用场景外，对于一些外部接口，例如N种奖品服务，可以由中台系统进行统一包装对外提供服务能力。也是中介者模式的一种思想体现。
在本案例中我们会把jdbc层进行包装，让用户在使用数据库服务的时候，可以和使用mybatis一样简单方便，通过这样的源码方式学习中介者模式，也方便对源码知识的拓展学习，增强知识栈。
##总结
- 以上通过中介者模式的设计思想我们手写了一个ORM框架，隐去了对数据库操作的复杂度，让外部的调用方可以非常简单的进行操作数据库。这也是我们平常使用的Mybatis的原型，在我们日常的开发使用中，只需要按照配置即可非常简单的操作数据库。
- 除了以上这种组件模式的开发外，还有服务接口的包装也可以使用中介者模式来实现。比如你们公司有很多的奖品接口需要在营销活动中对接，那么可以把这些奖品接口统一收到中台开发一个奖品中心，对外提供服务。这样就不需要每一个需要对接奖品的接口，都去找具体的提供者，而是找中台服务即可。
- 在上述的实现和测试使用中可以看到，这种模式的设计满足了；单一职责和开闭原则，也就符合了迪米特原则，即越少人知道越好。外部的人只需要按照需求进行调用，不需要知道具体的是如何实现的，复杂的一面已经有组件合作服务平台处理。
#第十七章、实战备忘录模式「模拟互联网系统上线过程中，配置文件回滚场景」
##前言
实现不了是研发的借口？
实现不了，有时候是功能复杂度较高难以实现，有时候是工期较短实现不完。而编码的行为又是一个不太好量化的过程，同样一个功能每个人的实现方式不一样，遇到开发问题解决问题的速度也不一样。除此之外还很不好给产品解释具体为什么要这个工期时间，这就像盖楼的图纸最终要多少水泥砂浆一样。那么这时研发会尽可能的去通过一些经验，制定流程规范、设计、开发、评审等，确定一个可以完成的时间范围，又避免风险的时间点后。再被压缩，往往会出一些矛盾点，能压缩要解释为什么之前要那么多时间，不能压缩又有各方不断施加的压力。因此有时候不一定是借口，是要考虑如何让整个团队健康的发展。
鼓励有时比压力要重要！
在学习的过程中，很多时候我们听到的都是，你要怎样，怎样，你瞧瞧谁谁谁，哪怕今天听不到这样的声音了，但因为曾经反复听到过而导致内心抗拒。虽然也知道自己要去学，但是很难坚持，学着学着就没有了方向，看到还有那么多不会的就更慌了，以至于最后心态崩了，更不愿意学。其实程序员的压力并不小，想成长几乎是需要一直的学习，就像似乎再也不敢说精通java了一样，知识量实在是随着学习的深入，越来越深，越来越广。所以需要，开心学习，快乐成长！
临阵的你好像一直很着急！
经常的听到；老师明天就要了你帮我弄弄吧、你给我写一下完事我就学这次着急、现在这不是没时间学吗快给我看看。其实看到的类似的还有很多，很纳闷你的着急怎么来的，不太可能，人在家中坐，祸从天上落。老师怎么就那个时间找你了，老板怎么就今天管你要了，还不是日积月累你没有学习，临时抱佛脚乱着急！即使后来真的有人帮你了，但最好不要放松，要尽快学会，躲得过初一还有初二呢！、
##备忘录模式介绍
备忘录模式是以可以恢复或者说回滚，配置、版本、悔棋为核心功能的设计模式，而这种设计模式属于行为模式。在功能实现上是以不破坏原对象为基础增加备忘录操作类，记录原对象的行为从而实现备忘录模式。
这个设计在我们平常的生活或者开发中也是比较常见的，比如：后悔药、孟婆汤(一下回滚到0)，IDEA编辑和撤销、小霸王游戏机存档。当然还有我们非常常见的历史头像，如下；
##案例场景模拟
在本案例中我们模拟系统在发布上线的过程中记录线上配置文件用于紧急回滚
在大型互联网公司系统的发布上线一定是易用、安全、可处理紧急状况的，同时为了可以隔离线上和本地环境，一般会把配置文件抽取出来放到线上，避免有人误操作导致本地的配置内容发布出去。同时线上的配置文件也会在每次变更的时候进行记录，包括；版本号、时间、MD5、内容信息和操作人。
在后续上线时如果发现紧急问题，系统就会需要回滚操作，如果执行回滚那么也可以设置配置文件是否回滚。因为每一个版本的系统可能会随着带着一些配置文件的信息，这个时候就可以很方便的让系统与配置文件一起回滚操作。
我们接下来就使用备忘录模式，模拟如何记录配置文件信息。实际的使用过程中还会将信息存放到库中进行保存，这里暂时只是使用内存记录。
##总结
- 此种设计模式的方式可以满足在不破坏原有属性类的基础上，扩充了备忘录的功能。虽然和我们平时使用的思路是一样的，但在具体实现上还可以细细品味，这样的方式在一些源码中也有所体现。
- 在以上的实现中我们是将配置模拟存放到内存中，如果关机了会导致配置信息丢失，因为在一些真实的场景里还是需要存放到数据库中。那么此种存放到内存中进行回复的场景也不是没有，比如；Photoshop、运营人员操作ERP配置活动，那么也就是即时性的一般不需要存放到库中进行恢复。另外如果是使用内存方式存放备忘录，需要考虑存储问题，避免造成内存大量消耗。
- 设计模式的学习都是为了更好的写出可扩展、可管理、易维护的代码，而这个学习的过程需要自己不断的尝试实际操作，理论的知识与实际结合还有很长一段距离。切记多多上手！
#第十八章、实战观察者模式「模拟类似小客车指标摇号过程，监听消息通知用户中签场景」
##前言
知道的越多不知道的就越多
编程开发这条路上的知识是无穷无尽的，就像以前你敢说精通Java，到后来学到越来越多只想写了解Java，过了几年现在可能想说懂一点点Java。当视野和格局的扩大，会让我们越来越发现原来的看法是多么浅显，这就像站在地球看地球和站在宇宙看地球一样。但正因为胸怀和眼界的提升让我们有了更多的认识，也逐渐学会了更多的技能。虽然不知道的越来越多，但也因此给自己填充了更多的技术栈，让自己越来越强大。
拒绝学习的惰性很可怕
现在与以前不一样，资料多、途径广，在这中间夹杂的广告也非常多。这就让很多初学者很难找到自己要的知识，最后看到有人推荐相关学习资料立刻屏蔽、删除，但同时技术优秀的资料也不能让需要的人看见了。久而久之把更多的时间精力都放在游戏、娱乐、影音上，适当的放松是可以的，但往往沉迷以后就很难出来，因此需要做好一些可以让自己成长的计划，稍有克制。
平衡好软件设计和实现成本的度°
有时候一个软件的架构设计需要符合当前条件下的各项因素，往往不能因为心中想当然的有某个蓝图，就去开始执行。也许虽然你的设计是非常优秀的，但是放在当前环境下很难满足业务的时间要求，当一个业务的基本诉求不能满足后，就很难拉动市场。没有产品的DAU支撑，最后整个研发的项目也会因此停滞。但研发又不能一团乱麻的写代码，因此需要找好一个适合的度，比如可以搭建良好的地基，实现上可扩展。但在具体的功能上可以先简化实现，随着活下来了再继续完善迭代。
##观察者模式介绍
简单来讲观察者🕵模式，就是当一个行为发生时传递信息给另外一个用户接收做出相应的处理，两者之间没有直接的耦合关联。例如；狗仔队
除了生活中的场景外，在我们编程开发中也会常用到一些观察者的模式或者组件，例如我们经常使用的MQ服务，虽然MQ服务是有一个通知中心并不是每一个类服务进行通知，但整体上也可以算作是观察者模式的思路设计。再比如可能有做过的一些类似事件监听总线，让主线服务与其他辅线业务服务分离，为了使系统降低耦合和增强扩展性，也会使用观察者模式进行处理。
##案例场景模拟
在本案例中我们模拟每次小客车指标摇号事件通知场景(真实的不会由官网给你发消息)
可能大部分人看到这个案例一定会想到自己每次摇号都不中的场景，收到一个遗憾的短信通知。当然目前的摇号系统并不会给你发短信，而是由百度或者一些其他插件发的短信。那么假如这个类似的摇号功能如果由你来开发，并且需要对外部的用户做一些事件通知以及需要在主流程外再添加一些额外的辅助流程时该如何处理呢？
基本很多人对于这样的通知事件类的实现往往比较粗犷，直接在类里面就添加了。1是考虑🤔这可能不会怎么扩展，2是压根就没考虑😄过。但如果你有仔细思考过你的核心类功能会发现，这里面有一些核心主链路，还有一部分是辅助功能。比如完成了某个行为后需要触发MQ给外部，以及做一些消息PUSH给用户等，这些都不算做是核心流程链路，是可以通过事件通知的方式进行处理。
那么接下来我们就使用这样的设计模式来优化重构此场景下的代码。
##总结
- 从我们最基本的过程式开发以及后来使用观察者模式面向对象开发，可以看到设计模式改造后，拆分出了核心流程与辅助流程的代码。一般代码中的核心流程不会经常变化。但辅助流程会随着业务的各种变化而变化，包括；营销、裂变、促活等等，因此使用设计模式架设代码就显得非常有必要。
- 此种设计模式从结构上是满足开闭原则的，当你需要新增其他的监听事件或者修改监听逻辑，是不需要改动事件处理类的。但是可能你不能控制调用顺序以及需要做一些事件结果的返回继续操作，所以使用的过程时需要考虑场景的合理性。
- 任何一种设计模式有时候都不是单独使用的，需要结合其他模式共同建设。另外设计模式的使用是为了让代码更加易于扩展和维护，不能因为添加设计模式而把结构处理更加复杂以及难以维护。这样的合理使用的经验需要大量的实际操作练习而来。
#第十九章实战状态模式「模拟系统营销活动，状态流程审核发布上线场景」
##前言
写好代码三个关键点
如果把写代码想象成家里的软装，你肯定会想到家里需要有一个非常不错格局最好是南北通透的，买回来的家具最好是品牌保证质量的，之后呢是大小合适，不能摆放完了看着别扭。那么把这一过程抽象成写代码就是需要三个核心的关键点；架构(房间的格局)、命名(品牌和质量)、注释(尺寸大小说明书)，只有这三个点都做好才能完成出一套赏心悦目的家。
平原走码🐎易放难收
上学期间你写了多少代码？上班一年你能写多少代码？回家自己学习写了多少代码？个人素养的技术栈地基都是一块一块砖码出来的，写的越广越深，根基就越牢固。当根基牢固了以后在再上层建设就变得迎刃而解了，也更容易建设了。往往最难的就是一层一层阶段的突破，突破就像破壳一样，也像夯实地基，短时间看不到成绩，也看不出高度。但以后谁能走的稳，就靠着默默的沉淀。
技术传承的重要性
可能是现在时间节奏太快，一个需求下来恨不得当天就上线(这个需求很简单，怎么实现我不管，明天上线！)，导致团队的人都很慌、很急、很累、很崩溃，最终反反复复的人员更替，项目在这个过程中也交接了N次，文档不全、代码混乱、错综复杂，谁在后面接手也都只能修修补补，就像烂尾楼。这个没有传承、没有沉淀的项目，很难跟随业务的发展。最终！根基不牢，一地鸡毛。
##状态模式介绍
状态模式描述的是一个行为下的多种状态变更，比如我们最常见的一个网站的页面，在你登录与不登录下展示的内容是略有差异的(不登录不能展示个人信息)，而这种登录与不登录就是我们通过改变状态，而让整个行为发生了变化。
至少80后、90后的小伙伴基本都用过这种磁带放音机(可能没有这个好看)，它的上面是一排按钮，当放入磁带后，通过上面的按钮就可以让放音机播放磁带上的内容(listen to 英语听力考试)，而且有些按钮是互斥的，当在某个状态下才可以按另外的按钮(这在设计模式里也是一个关键的点)。
##案例场景模拟
在本案例中我们模拟营销活动审核状态流转场景(一个活动的上线是多个层级审核上线的)
在上图中也可以看到我们的流程节点中包括了各个状态到下一个状态扭转的关联条件，比如；审核通过才能到活动中，而不能从编辑中直接到活动中，而这些状态的转变就是我们要完成的场景处理。
大部分程序员基本都开发过类似的业务场景，需要对活动或者一些配置需要审核后才能对外发布，而这个审核的过程往往会随着系统的重要程度而设立多级控制，来保证一个活动可以安全上线，避免造成资损。
当然有时候会用到一些审批流的过程配置，也是非常方便开发类似的流程的，也可以在配置中设定某个节点的审批人员。但这不是我们主要体现的点，在本案例中我们主要是模拟学习对一个活动的多个状态节点的审核控制。
##总结
- 从以上的两种方式对一个需求的实现中可以看到，在第二种使用设计模式处理后已经没有了ifelse，代码的结构也更加清晰易于扩展。这就是设计模式的好处，可以非常强大的改变原有代码的结构，让以后的扩展和维护都变得容易些。
- 在实现结构的编码方式上可以看到这不再是面向过程的编程，而是面向对象的结构。并且这样的设计模式满足了单一职责和开闭原则，当你只有满足这样的结构下才会发现代码的扩展是容易的，也就是增加和修改功能不会影响整体的变化。
- 但如果状态和各项流转较多像本文的案例中，就会产生较多的实现类。因此可能也会让代码的实现上带来了时间成本，因为如果遇到这样的场景可以按需评估投入回报率。主要点在于看是否经常修改、是否可以做成组件化、抽离业务与非业务功能。
#第二十章、实战策略模式「模拟多种营销类型优惠券，折扣金额计算策略场景」
##策略模式介绍
策略模式是一种行为模式，也是替代大量ifelse的利器。它所能帮你解决的是场景，一般是具有同类可替代的行为逻辑算法场景。比如；不同类型的交易方式(信用卡、支付宝、微信)、生成唯一ID策略(UUID、DB自增、DB+Redis、雪花算法、Leaf算法)等，都可以使用策略模式进行行为包装，供给外部使用。
策略模式也有点像三国演义中诸葛亮给刘关张的锦囊；
- 第一个锦囊：见乔国老，并把刘备娶亲的事情du搞得东吴人尽皆知。
- 第二个锦囊：用谎言（曹操打荆州）骗泡在温柔乡里的刘备回去。
- 第三个锦囊：让孙夫人摆平东吴的追兵，她是孙权妹妹，东吴将领惧她三分。
##案例场景模拟
在本案例中我们模拟在购买商品时候使用的各种类型优惠券(满减、直减、折扣、n元购)
这个场景几乎也是大家的一个日常购物省钱渠道，购买商品的时候都希望找一些优惠券，让购买的商品更加实惠。而且到了大促的时候就会有更多的优惠券需要计算那些商品一起购买更加优惠！！！
这样的场景有时候用户用起来还是蛮爽的，但是最初这样功能的设定以及产品的不断迭代，对于程序员👨💻开发还是不太容易的。因为这里包括了很多的规则和优惠逻辑，所以我们模拟其中的一个计算优惠的方式，使用策略模式来实现。
##总结
- 以上的策略模式案例相对来说不并不复杂，主要的逻辑都是体现在关于不同种类优惠券的计算折扣策略上。结构相对来说也比较简单，在实际的开发中这样的设计模式也是非常常用的。另外这样的设计与命令模式、适配器模式结构相似，但是思路是有差异的。
- 通过策略设计模式的使用可以把我们方法中的if语句优化掉，大量的if语句使用会让代码难以扩展，也不好维护，同时在后期遇到各种问题也很难维护。在使用这样的设计模式后可以很好的满足隔离性与和扩展性，对于不断新增的需求也非常方便承接。
- 策略模式、适配器模式、组合模式等，在一些结构上是比较相似的，但是每一个模式是有自己的逻辑特点，在使用的过程中最佳的方式是经过较多的实践来吸取经验，为后续的研发设计提供更好的技术输出。
#第二十一章、实战模版模式「模拟爬虫各类电商商品，生成营销推广海报场景」
##模版模式介绍
模板模式的核心设计思路是通过在，抽象类中定义抽象方法的执行顺序，并将抽象方法设定为只有子类实现，但不设计独立访问的方法。简单说也就是把你安排的明明白白的。
就像西游记的99八十一难，基本每一关都是；师傅被掳走、打妖怪、妖怪被收走，具体什么妖怪你自己定义，怎么打你想办法，最后收走还是弄死看你本事，我只定义执行顺序和基本策略，具体的每一难由观音来安排。
##案例场景模拟
在本案例中我们模拟爬虫各类电商商品，生成营销推广海报场景
关于模版模式的核心点在于由抽象类定义抽象方法执行策略，也就是说父类规定了好一系列的执行标准，这些标准的串联成一整套业务流程。
在这个场景中我们模拟爬虫爬取各类商家的商品信息，生成推广海报(海报中含带个人的邀请码)赚取商品返利。声明，这里是模拟爬取，并没有真的爬取
而整个的爬取过程分为；模拟登录、爬取信息、生成海报，这三个步骤，另外；
- 因为有些商品只有登录后才可以爬取，并且登录可以看到一些特定的价格这与未登录用户看到的价格不同。
- 不同的电商网站爬取方式不同，解析方式也不同，因此可以作为每一个实现类中的特定实现。
- 生成海报的步骤基本一样，但会有特定的商品来源标识。所以这样三个步骤可以使用模版模式来设定，并有具体的场景做子类实现。
##总结
- 通过上面的实现可以看到模版模式在定义统一结构也就是执行标准上非常方便，也就很好的控制了后续的实现者不用关心调用逻辑，按照统一方式执行。那么类的继承者只需要关心具体的业务逻辑实现即可。
- 另外模版模式也是为了解决子类通用方法，放到父类中设计的优化。让每一个子类只做子类需要完成的内容，而不需要关心其他逻辑。这样提取公用代码，行为由父类管理，扩展可变部分，也就非常有利于开发拓展和迭代。
- 但每一种设计模式都有自己的特定场景，如果超过场景外的建设就需要额外考虑🤔其他模式的运用。而不是非要生搬硬套，否则自己不清楚为什么这么做，也很难让后续者继续维护代码。而想要活学活用就需要多加练习，有实践的经历。
#第二十二章、实战访问者模式「模拟家长与校长，对学生和老师的不同视角信息的访问场景」
#前言
能力，是你前行的最大保障
年龄会不断的增长，但是什么才能让你不慌张。一定是能力，即使是在一个看似还很安稳的工作中也是一样，只有拥有能留下的本事和跳出去的能力，你才会是安稳的。而能力的提升是不断突破自己的未知也就是拓展宽度，以及在专业领域建设个人影响力也就是深度。如果日复日365天，天天搬砖，一切都没有变化的重复只能让手上增长点老茧，岁月又叹人生苦短。
站得高看的远吗？
站得高确实能看得远，也能给自己更多的追求。但，站的高了，原本看的清的东西就变得看不清了。视角和重点的不同，会让我们有很多不同的选择，而脚踏实地是给自己奠定能攀升起来的基石，当真的可以四平八稳的走向山头的时候，才是适合看到更远的时候。
数学好才能学编码吗
往往很多时候学编程的初学者都会问数学不好能学会吗？其实可以想想那为什么数学不好呢？在这条没学好的路上，你为它们付出了多少时间呢？如果一件事情你敢做到和写自己名字一样熟悉，还真的有难的东西吗。从大学到毕业能写出40万行代码的，还能愁找不到工作吗，日积月累，每一天并没有多难。难的你想用最后一个月的时间学完人家四年努力的成绩的。学习，要趁早。
##访问者模式介绍
访问者要解决的核心事项是，在一个稳定的数据结构下，例如用户信息、雇员信息等，增加易变的业务访问逻辑。为了增强扩展性，将这两部分的业务解耦的一种设计模式。
说白了访问者模式的核心在于同一个事物不同视角下的访问信息不同，比如一个美女手里拿个冰激凌。小朋友会注意冰激凌，大朋友会找自己喜欢的地方观测敌情
##案例场景模拟
在本案例中我们模拟校园中的学生和老师对于不同用户的访问视角
这个案例场景我们模拟校园中有学生和老师两种身份的用户，那么对于家长和校长关心的角度来看，他们的视角是不同的。家长更关心孩子的成绩和老师的能力，校长更关心老师所在班级学生的人数和升学率{此处模拟的}。
那么这样学生和老师就是一个固定信息的内容，而想让不同视角的用户获取关心的信息，就比较适合使用观察者模式来实现，从而让实体与业务解耦，增强扩展性。但观察者模式的整体类结构相对复杂，需要梳理清楚再开发
##总结
- 从以上的业务场景中可以看到，在嵌入访问者模式后，可以让整个工程结构变得容易添加和修改。也就做到了系统服务之间的解耦，不至于为了不同类型信息的访问而增加很多多余的if判断或者类的强制转换。也就是通过这样的设计模式而让代码结构更加清晰。
- 另外在实现的过程可能你可能也发现了，定义抽象类的时候还需要等待访问者接口的定义，这样的设计首先从实现上会让代码的组织变得有些难度。另外从设计模式原则的角度来看，违背了迪米特原则，也就是最少知道原则。因此在使用上一定要符合场景的运用，以及提取这部分设计思想的精髓。
- 好的学习方式才好更容易接受知识，学习编程的更需要的不单单是看，而是操作。二十多种设计模式每一种都有自己的设计技巧，也可以说是巧妙之处，这些巧妙的地方往往是解决复杂难题的最佳视角。亲力亲为，才能为所欲为，为了自己的欲望而努力！