对于做网站有什么要求,新闻发布会视频,网站搜索推广方案论文,网站内页权重查询简介#xff1a; 设计模式是开发同学经常聊到的话题#xff0c;也经常被用到实际的开发项目中#xff0c;熟练的人可以做到信手拈来#xff0c;不熟悉的人陷入苦思冥想中。笔者认为#xff0c;不仅仅要掌握设计模式的用法#xff0c;更要洞察设计模式的底层逻辑#xff…简介 设计模式是开发同学经常聊到的话题也经常被用到实际的开发项目中熟练的人可以做到信手拈来不熟悉的人陷入苦思冥想中。笔者认为不仅仅要掌握设计模式的用法更要洞察设计模式的底层逻辑只有那样才能做到遇到实际的问题可以使用合适的设计模式去解决。 作者 | 不拔 来源 | 阿里技术公众号
设计模式是开发同学经常聊到的话题也经常被用到实际的开发项目中熟练的人可以做到信手拈来不熟悉的人陷入苦思冥想中。笔者认为不仅仅要掌握设计模式的用法更要洞察设计模式的底层逻辑只有那样才能做到遇到实际的问题可以使用合适的设计模式去解决。
一 你应该关注底层逻辑
1 设计模式的段子
段子一你让他给你讲设计模式他给你讲故事听完后又蹦又跳乐坏了看原著设计模式和实际写代码时又是又蹦又跳那是疯了。
段子二你让他给你讲设计模式他给你讲架构你和他讲架构他和你讲建筑学你和他讲建筑学他和你讲哲学……
上面两个典型的段子可以看到大家平时学习设计模式的无奈故事听懂了但依然没有掌握设计模式甚至设计模式的类图大家也画得出却还是不能灵活掌握设计模式。究其根本的原因是没有掌握设计模式的内核思想只是知道设计模式的外在形式相当于只学到了“招式”没有学到“内功”。
2 底层逻辑的本质
很多事物都有底层逻辑当掌握了事物的底层逻辑之后很多事就好办了如果你已经洞察到了最核心的规律在实际工作中就只需要按照规律去执行就可以。例如我们看到很多营销文案让人眼前一亮、叹为观止如果要让我们去写这些营销文案一开始还找不到门道写出来的标题平平淡淡不够吸引人。那营销文案背后的底层逻辑是什么呢我们看到很多文案如“激发学习潜能的四大策略”、“如何在10天内记忆5000单词”、“一文提示为什么你比别人差”……这些文案有的使用陈述手法有的使用疑问手法有的使用对比手法有的使用感叹手法……再往下挖掘不管使用哪种手法本质来讲是命中了人的爽点或痛点再用这个底层逻辑去看各种文案有的命中你的痛点比如你想记忆更多的单词现实记不住单词比如你想成功但努力了很久还没有效果……有的命中你的爽点你花更少的钱就能获得更好的服务你不用出门就能赚到钱……当你洞察到了营销文案背后的底层逻辑你现在也可以写出吸引眼球的文案这就是底层逻辑的力量
我们学习23种设计模式它们被划分成创建型设计模式、结构型设计模式、行为型设计模式这就像营销文案的写作手法一样那么设计模式的底层逻辑到底是什么呢 二 设计模式的底层逻辑
1 设计模式的基石
平时我们在写代码的时候经常见到如下三种类型的代码面条型的代码、过程式的代码和面向对象的代码这里以一个例子来说明这三种类型的编码特点。
面条型代码就是所有逻辑堆砌在一起就像写一篇文章不怎么分段落。比如古代雕刻文字在一块木板上雕刻一首诗如果诗人要把其中的一个修改下那得重新雕刻这首诗。非常容易发现这种模式的缺点耦合太严重牵一发而动全身。过程式代码在面条型代码基础上有了很大的进步它遵循“自顶向下逐步求精”的思想把一个大问题划分成若干个小问题分而治之。对应上面雕刻诗的例子诗是由若干个行组成的如果每块木板上只雕刻一行诗万一要改某个字只用重新雕刻那一行就行不用重新雕刻整首诗。但如果要修改多个字而且在不同的行时这种极端情况下整个首诗又得重新雕刻了。面向对象代码换了一种思考方式诗是由行组成的行又是由一个个字组成的这也即是活字印刷的思想这些字还可以复用于其它不同的诗复用性非常强。
从上面的例子可以看到核心还是洞察到事物的结构和关系首先回答的是what而不是how。过程式就是过分强调了how一开始就思考怎么去做过程式思维是以自己为中心导演了整个功能流程自己承担了太多自己不应该承担的职责整个设计就显得不灵活。面向对象是从对象的角度去看问题解决问题是由各个对象协作完成设计模式的基石就是面向对象脱离了面向对象去谈设计模式那是耍流氓。
2 设计模式的鼻祖
设计模式有一本经典的书籍《设计模式可复用面向对象软件的基础》在书中作者提到了一句话“找到变化封装变化”这才是设计模式的底层逻辑。很多人忽视了这句话反而去追寻各种模式的招式遇到实际的问题又找不到合适的设计模式去解决了。“找到变化封装变化”非常精练地提示了设计模式的本质细细品味这句话再去看23种设计模式每种设计模式都在应对变化的事比如策略模式具体的策略在变化工厂模式创建的对象在变化模板模式具体模板算法实现在变化……这就好比营销文案的底层逻辑命中了你的痛点或爽点具体痛点和爽点是什么需要去寻找。在实际问题中需要我们去看什么在变化选择哪种设计模式比较合适。
3 再谈底层逻辑
再回过头看底层逻辑平时我们看到的现象只是现象层核心是要洞察到事物的底层逻辑只有那样才能真正理解现象、运用规律如果你不懂营销文案背后的底层逻辑你所有的勤奋都是低水平的重复很难写出高质量的营销文案偶尔一两次起得了良好的效果你也不知道为什么能吸引人。设计模式也是一样你能熟悉地画出各种模式的UML图可你依然还是用不好设计模式本质还是没有掌握设计模式的底层逻辑只看到了设计模式的现象层的招式。设计模式的底层逻辑是“找到变化封装变化”这里就有两个问题什么在变化如何封装变化大师以为我们都知道所以并没有讲具体怎么去寻找变化怎么去封装变化。接下来具体谈谈怎么去运用设计模式的底层逻辑。 三 设计模式要回答的两个问题
1 什么在变化
“找到变化封装变化”这句话首先要回答的是什么在变化如果变化没有找到就不可能封装变化。笔者这里以对象生命周期的视角去看待对象的变化对象是由创建而产生然后被使用最后是消亡。对象有三个不同维度的变化对象结构的变化、对象规格的变化、对象行为的变化。以对象结构变化为例对象的关系划分成两类线性关系和非线性关系树和图在线性关系中如何解决一个对象的变化不会影响到关联的对象在树型结构中如何解决不断新增加对象的问题在图型结构中如何解决用户方便使用复杂系统的问题
找到变化是最为关键不同的业务问题遇到的变化问题也是不一样的核心是要找到这些变化。比如对象规格的变化有数量的变化、类型的变化、外观的变化在实际编码的过程中就要有这种思考比如创建一个对象再深入思想下有没有其它类型的对象数量有没有变化……只有找到了这些变化具体怎么去封装变化就是技术的问题接下来讨论如何封装变化。
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 应对非线性变化
非线性关系比线性关系要复杂常见也有两种方法一种是通过注册机制另一种通过抽象层屏蔽复杂性。当一个对象包含多个对象时如果直接去管理需要承担的职责太多通过注册机制就比较好解决增加一个对象是通过注册机制主动告知对象。另外一种方法就是通过抽象层屏蔽复杂性比如门面模式在门面内把所有的复杂度都规避对外提供简洁的接口。 五 业务变化之道
设计模式还是要应用到实际的业务中才能发挥它的价值 Alan Shalloway 提到一个观点无法预测哪里有变化但能知道哪里可能有变化。平时我们在做业务需求开发时要有这种识别变化的意识先不要陷入面向过程的思维中不要一上来就考虑如何去实现而是思考它是什么会有哪些变化比如对象的数量、对象的外观、对象的种类……当把这些思考清楚之后才能设计得更合理。
比如笔者之前做清结算业务时投资人理财到期后会将本息金额的钱打给投资人刚开始只有大华支付通道这里就要想到一个问题大华支付只是一种具体的实现方式还会有没有其它的支付方式如果有就要做抽象设计设计一个通用的支付模板类每接一种新的支付通道时只用重写模板类中的几个方法即可后续又接了民生银行支付、连连支付。 六 对象设计之道
有了前面所讲内容的铺垫这里再深入总结下对象设计的一些思考。对象设计有三个问题有哪些对象对象之间的关系是怎样的对象的职责有哪些当把这三个问题梳理清楚了对象设计也就容易得多也是面向对象分析与设计的核心。正常来讲我们知道结构决定功能功能决定行为这是非常符合人的逻辑认识但要想了解清楚对象的结构又是非常难的就像新冠病毒的分子结构也不是那么容易破解的尤其是复杂业务它所包含的业务对象并不那么容易弄清楚它的结构。
我们可以反过来思考当有一种业务场景时先思考它的职责是什么再去思考应该由哪些业务对象去承担这也是典型的归纳思维。比如在优惠券业务中它的业务活动就三个建券、发券、用券也就是任何一个优惠券系统它要提供这三个最为基础的能力这三个能力又对应到两个业务对象券批次和券实例券批次相当于是券的模板告知优惠券的预算有多少、券面额是多少、使用条件是什么……具体发放到用户手上的才是券实例。
当有了业务对象之后就要通过用例去思考对象模型的所包含的属性和方法有哪些这个过程并不是一次就能完美完成的而是通过多次打磨才行这里面就要遵循一些原则比如单一职责、开闭原则、依赖倒置的原则……让整个模型的可扩展性更好。 七 一个案例
最后拿一个案例来讲店铺类目是卖家为了方便买家有针对性地选购商品而对商品做出的归类比如上新类目把最近30天上架的商品归类在一起方便买家查找。遇到的挑战就是怎么用一套业务模型去支持不同业务方高度定制化的需求有的需求方要求有三级类目有的业务方要求浮动的两级类目同时圈品方式也不一样有的业务方要求有自动圈选商品圈选商品的条件还不一样如按价格圈选、按商品上架时间圈选、按评价圈选……
怎么去设计这套模型呢还是从店铺类目的定义去看店铺类目至少包含两个关键的要素类目结构和类目圈品因为归类产生了结构商品产生了圈品考虑到类目有不同的层级和圈品条件所以第一版模型就很快设计出来了从模型中可以看到能支撑业务的诉求尤其是圈品条件中业务方可以自定义各种条件注册到平台上看到这个设计笔者内心还是欣慰的。
但在实现的过程中发现了一些问题如根类目和子类目在业务模型中有这两个概念在代码上也要有这两个概念正是引入了这两个概念代码写起来就比较麻烦本身它们并没有什么区别现在人为地把它们区分开来很多逻辑都要写两遍。笔者又进模型进行了优化变成了第二版模型这个模型就更简单了。
这里想谈的两点是要保证模型的简洁性和降低技术复杂度技术人喜欢钻研技术喜欢把一些学到的技术应用到项目中这实际上是一种技术偏见以为这样才能体现出技术复杂度和技术能力。复杂并不见得有技术含量就像设计模式的底层规律作者并没有长篇大谈而是只有8个字找到变化封装变化大道至简就是这个道理我们学习设计模式不要为了用设计模式而用一定要思考为什么用解决了什么问题这样才有价值。 原文链接
本文为阿里云原创内容未经允许不得转载。
