附录

本章节属于一个比较特殊的章节,不定时更新,想到什么写什么。内容或是个人的一些感悟感想,或是对专栏中某个章节内容知识点的补充(有些知识点需要较大篇幅,不便在主体内容中体现),推荐读者阅读。

设计模式到底有什么用

设计模式,相信基本每一个开发者都或多或少听过,至于运用了多少就不得而知了。当然这小节并不打算跟大家把每个设计模式都过一遍,因为内容量太大,随便都是一本书的级别,在没有打赏的前提下,我不想写(收到一条群消息:都2020年了,沁尘的专栏还不更新)。本小节主要想和大家分享的是关于我对设计模式的理解,相信通过阅读本小节的内容,能让你对设计模式有个清晰的认识,在日后学习和运用设计模式的过程中可以少走弯路。

和大多数人一样,我一开始也是通过百度或者买书去学设计模式,在学习了一段时间之后的感触就是:设计模式太棒了,但是我好像用不着。不知道显示器前的你是不是也有这种想法,我一度很困惑,我写的项目,设计模式?不存在的。能运行吗?没问题。那我要设计干嘛呢?本来几行代码可以实现的逻辑,我可能要各种拆分和抽象,折腾出什么工厂类(工厂还分简单和抽象)。就在我百思不得其解的时候,突然一句话让我瞬间顿悟:世上无难事,只要肯放弃。是的,于是我干脆就不想这个问题了,继续写我的代码。当然故事肯定不可能这样就结束了,接下来的日子就是漫长的打脸岁月。项目两年时间里为了满足业务的增长和各种变化的需求,前前后后重构了三次,基本都是推倒重来的局面,上线后各种深夜修BUG那是家常便饭。这样的生活严重压缩了我的游戏时间,于是我开始想办法解决这个问题,我开始使用一些封装或者抽象来让各个功能模块做到尽可能的易于改动和扩展,而就在这个过程中,我发现写着写着有种似曾相似的感觉,似乎在哪看过,没错!是它!设计模式!于是乎,我赶紧翻开那尘封已久的设计模式相关书籍,再一次阅读那些曾经我“看了等于会了”的章节,瞬间有种顿悟的感觉,就在那一刻,我想明白了之前一直很困惑的那个问题的答案——不是设计模式无用,而是项目太小。当一个工程项目足够简单的时候,什么框架和面向对象、面向接口都是浮云,同理,给一个简单的工程项目引入什么设计模式那就是增加了项目的复杂度而且没收益的那种,因为根本就不需要。这里不妨回顾一下设计模式的由来,设计模式本身就是由无数业界大佬总结自己的编程经验而得出的,为了适应变化的解决方案,所以,如果你的项目本身就不会有啥变化或者变化很小,自然体会不到设计模式的作用。但是理论上不会变化的项目是不存在的(除非你这个项目已经凉了或者可有可无),既然有变化,我们就需要改代码。众所周知,改代码是有成本和风险的,而如何控制这个成本和风险就需要开发人员借助设计模式了。作为开发者,肯定不希望老是面对不停变化的需求,无论是从划水摸鱼的角度来说还是系统稳定性来说,但这是不现实的想法。想出设计模式的前辈们也是意识到了无法阻止变化和拒绝变化,所以总结了些套路,让我们学会拥抱变化

其实无论是从工作、学习、还是生活,个人觉得拥抱变化都是一种值得每个人拥有的态度。

看到这里,不知道读者们有没有又重新燃起了对设计模式的兴趣?当然即便没有也不要紧,只要你还写代码,你总会遇到给变化折磨得死去活来的一天,到时候你就会想到用设计模式了。最后我分享几点个人学习和运用设计模式的心得体会供读者参考:

  1. 设计模式需要理论和实践结合来学习,光看理论学不会。
  2. 看不同角度或者风格的设计模式书籍。
  3. 理论知识似懂非懂不要紧,留个印象即可。
  4. 多写项目。