设计模式是开发同学经常讨论的话题，在实际开发项目中也经常用到。熟练的人信手拈来，不熟悉的人陷入苦思冥想。笔者认为，不仅要掌握设计模式的用法，更要洞察设计模式的底层逻辑。只有这样，我们才能使用合适的设计模式来解决实际问题。一、底层逻辑你要注意1、设计模式的笑话。1、你让他给你讲设计模式，他给你讲故事。什么时候，跳啊跳，太疯狂了。Paragraph2：你让他给你讲设计模式，他给你讲架构；你和他谈建筑，他和你谈建筑；你和他谈架构，他和你谈哲学……以上两个典型的笑话中，可以看出大家平时学习设计模式的无奈。故事理解了，但是设计模式还是没有掌握。就连设计模式的类图人人都能画出来，但还是不能灵活掌握设计模式。根本原因是你没有掌握设计模式的核心思想，只知道设计模式的外在形式，相当于只学了“招式”，没有学“内功”。2底层逻辑的本质很多事物都有底层逻辑。掌握了事物的底层逻辑之后，很多事情就会好办了。如果洞察了核心规律，那么在实际工作中只需要按照规律去做就可以了。能。比如，我们看到很多营销文案，让人眼前一亮，让人叹为观止。如果让我们写这些营销文案，一开始我们找不到路，写的标题也很平淡，不够吸引人。营销文案背后的底层逻辑是什么？《激发学习潜能的四大策略》、《如何在10天内记住5000+单词》、《一篇文章提示为什么你比别人差》……这些文案我们见过很多，有的用疑问式的技巧，有的用对比式的技巧，有的用感叹式的技巧……深挖，不管用哪种技巧，本质上都是直击人的爽点或者痛点，然后用这个底层逻辑来看各种文案，有的击中了你的痛点，比如你想多背单词，但现实中记不住单词；例如，你想成功，但你努力了很久，没有效果……有些击中了你的酷点：你可以用更少的钱获得更好的服务；不出门也能赚钱……当你洞悉了营销文案背后的底层逻辑，你现在就可以写出吸引眼球的文案，这就是底层逻辑的力量！我们学习了23种设计模式，分为创建型设计模式、结构型设计模式和行为型设计模式。它到底是什么？二、设计模式的底层逻辑1、设计模式的基石通常我们在写代码的时候，经常会看到以下三种代码：面条式代码、过程式代码和面向对象代码。这里用一个例子来说明这三种类型的编码特点。面条代码就是把所有的逻辑堆在一起，就像写文章一样，不分段落。例如，在古代的雕刻中，如果在木板上刻了一首诗，诗人如果要修改其中一首，就必须重新雕刻这首诗。这种模式的缺点很容易发现：耦合太严重，会影响到全身。程序代码在面条代码的基础上有了长足的进步。它遵循“自上而下，逐步求精”的思路，将一个大问题分解成若干个小问题，分而治之。对应上面刻诗的例子，这首诗是由几行组成的。如果每块木板上只刻一行诗，以防万一需要更改一个词，只需重新刻该行而不是整首诗。但如果要修改多个字，并且在不同的行中，在这种极端情况下，整首诗都必须重新雕刻。面向对象代码改变了思维方式。诗是由诗句组成的，诗词是由个别的人物组成的。这就是活字印刷的思路。这些字符也可以在其他不同的诗歌中重复使用。性很强。从上面的例子可以看出，核心是洞察事物的结构和关系，首先回答是什么，而不是如何。程序化的方法过于强调怎么做，从一开始就想着怎么做。程序化方法以自我为中心，指导整个功能过程，承担了太多不该承担的责任，使整个设计缺乏灵活性。面向对象就是站在对象的角度看问题。通过各种对象的合作解决问题。设计模式的基石是面向对象的。不面向对象就谈设计模式，就是耍流氓。2设计模式的鼻祖有一本关于设计模式的经典书籍：《设计模式：可复用面向对象软件的基础》，其中作者提到了一句话：“findchanges,encapsulatechanges”，这就是设计模式的底层逻辑。很多人忽略了这句话，转而追求各种花式走法。遇到实际问题时，找不到合适的设计模式来解决。“发现变化，封装变化”非常简洁的提醒了设计模式的精髓，细细品味这句话，再看23种设计模式，每一种设计模式都是在响应变化，比如策略模式，具体策略在工厂模式中，创建的对象正在改变；在模板模式下，具体模板算法的实现是变化的……这就像营销文案的底层逻辑：打你的痛点或者爽点，具体的痛点和爽点是什么？寻找。在实际问题中，我们要看变化的是什么，选择哪种设计模式更合适。3下面说说底层逻辑，回头看看底层逻辑。我们平时看到的现象，只是现象层。核心是洞察事物的底层逻辑。底层逻辑，你所有的努力都是低级重复，很难写出高质量的营销文案，一次两次就能达到很好的效果，不知道为什么有吸引力。设计模式也是如此。你可以熟练地绘制各种模式的UML图，但你仍然不能很好地使用设计模式。本质上，你还没有掌握设计模式的底层逻辑，只看到了设计模式的现象级动作。设计模式的底层逻辑是“发现变化，封装变化”。这里有两个问题：变化的是什么以及如何封装变化。大师认为我们都知道，所以他没有讲怎么找变化，怎么封装变化。接下来，我们来谈谈如何使用设计模式的底层逻辑。三种设计模式回答两个问题1什么是变化“发现变化，封装变化”，首先要回答的是变化是什么，如果没有发现变化，就不可能封装变化。作者从对象生命周期的角度来看对象的变化。对象被创建，然后被使用，最后消亡。对象在三个不同的维度上发生变化：对象结构的变化、对象规范的变化和对象行为的变化。以对象结构的变化为例，对象之间的关系分为线性关系和非线性关系（树和图）两种。在线性关系中，如何解决对象的变化不会影响关联对象的问题？在树形结构中如何解决不断添加新对象的问题？在图形化结构中，如何解决用户可以方便地使用复杂系统的问题？发现变化是最关键的。不同的业务问题有不同的变更问题。核心就是要找到这些变化。例如，对象规格的变化包括数量、类型和外观的变化。这种思考在实际编码过程中一定要考虑到，比如创建一个对象，然后深入思考，是否还有其他类型的对象？Quantity有没有变化？...只有找到这些变化，如何打包这些变化才是技术问题。接下来，我们将讨论如何打包更改。2如何封装变化从封装的类型来看，有数据的封装、方法的封装、类型的封装等，具体的封装方式有配置项、接口、抽象方法等常见的具体手段，类，注解，插件等。查找主要使用继承和组合的方法，查找封装的原则，常见的原则有单一职责，开闭原则，依赖倒置，隔离原则。。.大多数人通常更关注如何封装变化，而不会深入思考变化是什么。四、利用底层逻辑推导结构设计模式1、寻找对象结构的变化从UML看，对象之间的关系有依赖、泛化、组合、聚合，但结构关系只有两种，线性关系和非线性关系..线性关系比较简单，是一对一的关系。非线性关系分为树型关系和图型关系两种。关系结构的变化意味着依赖关系发生了变化。例如，在线性关系中，A所依赖的B发生了变化。这时候B的变化会影响到A，要考虑的是如何保证B的变化不影响A。问题。2处理线性变化上面说过，如果B发生变化，由于A依赖于B，那么对象A也会发生变化。如何减少对A的影响？这里有两种方法：一种是增加适配解决，另一种是通过代理解决。这两种方法的要点是一个对象并不直接与被改变的对象相关联。无论是适配还是代理，都是引入第三方与B进行关联，第三方负责与B进行交互，B对A没有任何感知。一些人立刻发现了问题。这不是把问题转移给第三方吗？乍一看，还真是这样。发散的想一下，如果A和B之间有关系，那么也有E和F……如果B把所有的关联对象都改了，成本会比较高。如果只是和第三方有关系，只需要换一个地方，成本就会少很多。3处理非线性变化非线性关系比线性关系复杂，常用的方法有两种：一种是通过注册机制，另一种是通过抽象层来屏蔽复杂性。当一个对象包含多个对象时，如果直接管理，需要承担太多的责任。最好通过注册机制来解决。添加对象就是通过注册机制主动通知对象。另一种方法是通过抽象层来屏蔽复杂性，比如门面模式，将所有的复杂性都规避在门面中，对外提供简洁的接口。业务变革的五种方式设计模式还是需要应用到实际业务中才能发挥其价值。AlanShalloway提到了一个观点：无法预测哪些地方会发生变化，但你可以知道哪些地方可能会发生变化。通常我们在开发业务需求的时候，一定要有这种识别变更的意识。不要陷入面向过程的思维。不要一上来就想着怎么实现，而是想着它是什么，会有什么变化，比如对象的个数，对象的外观，对象的种类……什么时候这些都想清楚了，设计才能更合理。比如笔者之前在做清算结算业务的时候，在投资者的理财到期后，会把本金和利息的钱汇给投资者。一开始只有大华支付渠道。这里有一个必须要思考的问题。大话支付只是一种具体的方式。实现方式，会不会有其他支付方式？如果是的话，就要做抽象设计，设计一个通用的支付模板类。当连接新的支付通道时，只需要重写模板类中的几个方法。不过民生银行的款和连连的款都是后来收到的。六。对象设计之道有了以上内容的铺垫，这里深度总结一下对象设计的一些思考。对象设计中存在三个问题：有什么对象？对象之间的关系是什么？对象的职责是什么？把这三个问题理清了，对象设计就容易多了，也是面向对象的分析设计。核。通常来说，我们知道结构决定功能，功能决定行为。这很符合人的逻辑，但是要理解一个对象的结构是非常困难的，就像新冠病毒的分子结构不是那么容易破译的，尤其是复杂的业务，它包含的业务对象不是那么容易破译的。很容易弄清楚它的结构。我们可以反过来想，当有一个业务场景的时候，先想它的职责是什么，然后再想应该由哪些业务对象来承担，这也是典型的归纳思维。例如在优惠券业务中，它有创建优惠券、发放优惠券、使用优惠券三个业务活动，即任何优惠券系统都必须提供这三个最基本的能力，而这三个能力对应两个业务对象：优惠券批次和优惠券实例。优惠券批次相当于优惠券的模板，告诉你优惠券的预算是多少，优惠券的面值是多少，使用条件是什么。具体分发给用户的是Coupon实例。当你有一个业务对象时，你需要通过用例来思考对象模型中包含的属性和方法。这个过程不可能一次就完美完成，而是要经过多次打磨。它必须遵循一些原则，比如单一职责、开放-封闭原则、依赖倒置原则……让整个模型更具可扩展性。七个案例最后，我们以一个案例为例。店铺类目是卖家为了方便买家有针对性地购买商品而对商品进行的分类。类集中在一起，方便买家查找。挑战在于如何用一套商业模式来支持不同业务方高度定制化的需求。有的需求方要求三级分类，有的业务方要求浮动二级分类。不一样的，有的业务方要求自动选品，选品的条件也不一样，比如按价格选，按产品发布时间选，按评价选……这个模型怎么设计？从店铺品类的定义来看，店铺品类至少包含两个关键要素：品类结构和品类圈品，因为品类产生结构，商品产生圈品。考虑到品类有不同的Level和circleproduct条件，所以很快就设计出了第一版模型。从模型中，我们可以看到能够支撑业务的需求，尤其是圈子产品条件。业务方可以自定义各种条件并在平台上注册。看到笔者对这样的设计还是很满意的。但是在实现的过程中，发现了一些问题，比如根类和子类。这两个概念存在于业务模型中，这两个概念也必须包含在代码中。就是引入了这两个概念。写代码比较麻烦，两者没有区别。现在人为区分了，很多逻辑要写两遍。作者进一步优化了模型，变成了第二版模型，更加简洁。这里我想讲的两点是保证模型的简单性和降低技术复杂度。技术人员喜欢研究技术，并将学到的一些技术应用到项目中。这其实是一种技术偏见，认为这样可以体现技术复杂度和技术能力。复杂不一定有技术含量，就像设计模式的底层规律一样，作者没有长篇大论，只是8个字“发现变化，封装变化”，这就是大道至简的道理，我们学习设计模式，千万不要为了使用设计模式，你必须思考为什么使用它，它解决什么问题，这样它才有价值。
