将程序中的变与不变分开，你真的懂我说的是什么？
导语：虽然我是一个无情的打工仔，但是我有一颗向上的心。我准备新开一个系列和大家好好聊聊自学的时候看不上，现在奉为宗旨（夸张）的设计模式。
我自学编程的时候，真的没有去仔细了解过设计模式这种东西，因为它总是被我贴上了玄幻的标签。
没办法，线性思维的我总是觉得敲代码就是为了解决问题，解决问题又不能弯道超车，设计模式这种他人眼里的思路简单稍微理解一下就行了，当真岂不是意味着被同化了嘛。
当时的我，对设计模式的了解都是为了应付未来的面试，但是入职以后血淋淋的现实告诉我，熟练掌握设计模式到底有多重要。
言归正传，我们既然要聊设计模式，就得知道设计模式的前世今生吧，哪怕你不感兴趣它的历史，你也总得知道它是什么吧。
所以看到这的小伙伴别急，我现在就要开始正式介绍设计模式了。
什么是设计模式
百度出来的设计模式（Design Pattern）指的是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。设计模式代表了最佳的实践，是软件开发人员在软件开发过程中面临的一般问题的解决方案。
其目的有四：
提升代码的重用性
提升代码的可阅性
提升代码的可靠性
提升代码的可拓展性
先前的对设计模式的理解是不是太枯燥，来看看我对设计模式的理解。
设计模式就是一本三十六计，它不是毫无根据、虚无缥缈的坊间传说，而是你的无数码农前辈以自己和祖传烂代码之间丰富的斗争经验而总结出的兵书。
仔细想想，设计模式的背后是码农们在实际项目中无数次掉坑、爬坑、填坑的过程，不敢说是血与汗，最少也是吃了各种教训的前辈们的一个个无辜的毛囊。
热情好心的前辈们为了不让我们后辈重蹈覆辙，忍痛把过去的实际经验抽象成一个个设计模式。可以说设计模式的出现，才让敲代码变得有条理。
不用去怀疑，熟练掌握设计模式的你，不敢说一步登天成为能造轮子的大牛，最少也能拿捏项目开发中的简单脉络，知道怎么去下手解决问题。
我可没有夸大其词，如果你还是用之前漫无目的的发散思维去设计自己的代码，或者根本没有设计这个环节而是直接动手的尝试，当你代码写的越来越多的时候反而是你越来越痛苦的时候。
上面这位知乎老哥的回答我就很喜欢，像我之前一样觉得设计模式没用，现在看来其本质上就是因为上手的项目太少，自己动手敲过的代码太少。
我自学的时候想着设计模式不过是在笔试的时候会考到，也就是介绍一下某个设计模式的优缺点，最多是用某一语言以不同的方法实现一下，或者对比几个设计模式之间的区别。
真正面试的时候关于设计模式的比重还没有笔试的时候多，加上学这种抽象的东西很容易枯燥乏味，我内心就很抗拒，刻意淡化了这些基础知识。当时的我真的是 too young too simple。
现在看来，设计模式本身没有什么故弄玄虚的地方，也没什么特殊的身份，它不过是将本该由你思考需求，不断踩坑去寻求解决方案的这个过程，前人早已帮你系统化总结好了。
对于现成的设计思路，你要做的不过是为图纸添砖加瓦，至于选什么砖，怎么砌砖都得看你的手艺了。
但毫无疑问，设计模式于己于他人于项目本身都是多赢的。
我们可能达不到大神的高度，一辈子也创新不出神奇的算法，但我们只要熟练掌握了设计模式，并且能写出高质量的代码，我们就足以胜任各种场景了。
如果你要现在问我对设计模式的态度？
那就是一定要学，但不要学的太死板，它不是定理也不是原则，它是一种解决问题的潜在思路，具体怎么用还是要见招拆招。
当你代码量小的时候可能总结不出什么，甚至代码量大了也可能总结不出什么，但等你熟悉了项目的开发、迭代、重构、重写、维护以后，你一定会认可设计模式的存在。
当初我在学习设计模式的时候见过很多人说，设计模式的本质就是解耦，而其他的框架都是万变不离其宗，我越琢磨越觉得是这么回事。
将设计模式变成你面对需求时思考的本能习惯，我大概后面很多年都会为了这个目标而努力吧。
设计模式的过去
总觉得刚刚跑题很严重，不过都是我对设计模式的思考，仅代表个人想法。现在再次回归正题，来聊聊设计模式的过去。
设计模式的首次提出是1994年由 GOF（俗称四人帮）合著的一本名为《设计模式-可复用的面向对象软件元素》的书中所介绍的。
这本书中的每一章最后都清清楚楚的记述了设计模式的由来，可以说每一个设计模式都是对当时已有的实用软件的总结。
不过那本书更多是针对当时关于 C++ 这个语言本身存在的问题，何况至今快 30 年的历史了，内容过时也是无可避免的，喜欢“考古”的小伙伴还是可以去瞅瞅的
。
结论
我们要理性看待设计模式，不要怀疑前人的智慧，但也别硬搬硬套，无脑吹捧。
面对不同的复杂需求，你要做到是多思考，争取能从已有的设计模式中找到思路，然后再去尝试实现。
最后提一嘴我说的这个系列我是准备用 Python 实现，争取用大家都能看懂的大白话把那几种设计模式讲清楚，这也是我自己的总结吧。至于介绍设计模式的顺序我就随意了啊~
敬请期待:)