学习资源分享
作为程序员，其实多多少少，都会听过设计模式这个概念。刚开始的时候，会觉得比较专业。随便网页一搜，都是十几二十几种，一看头都大了。
我前两年的时候，也确实学习看过一些书籍，也照着例子，搬过来运行了。实话，那时候，除了单例模式，啥都没怎么看懂。就只知道一堆嵌套和堆积的调用。直到这些年，开始接触了java后端的活，也看了同事的很多代码，慢慢地对设计这个概念，有了自己的认知。
然后，我就开始重新学起来了，很幸运，我这回在网上找到了一个网站。这个网站吧，例子很详细，前因后果，使用场景等，都说得很清楚。
网站链接：https://refactoringguru.cn/design-patterns
这个网站，我觉得还有一个点比较令我满意，就是代码涵盖很多常用的语言类型，java/go等。
而且，代码的场景也足够有深度和复杂度，可以让人去琢磨。代码全程实现下来，没有任何bug，实在是一个很良心的网站。
当然，如果有些例子看不懂，没关系，再在其他网站上找找学学，也是可以的。
总结
结构化的编程思维
程序，其实就是算法+数据。
但是，如果结合一些设计思维，我们的程序就得呈现结构化的阵型了。
这里，我其实之前就没意识到，程序是需要一些组织形式去呈现的。作为程序员，很容易陷在需求里的一亩三分地，导致被动修改的局面。但我们也无法时刻保证自己都能去参与大型系统的设计，多数时候，都在一个模块里打转，如果缺乏外在推动，其实是很难主动来审视自己的产出。
我也是参考了上述网站在实现一个设计模式的过程中，慢慢体会到了，如何去设计一个模块，主要需要如下几个思维。
输入输出的思维。要把自己的程序能按照数据流动的方式去设计。
内外的思维。对内，是我们的算法和业务，对外，是我们的进出接口。确保使用方能按照既定的约束去完成使用。
随时接受变更的思维。在设计的时候，需要思考自己的系统，会在哪里需要出现拓展，哪里可能会出现质量加固的诉求。
基本的逻辑框架：
我们应该要思考的重点，应该在于业务处理模块：
有没有可能，要把整个业务处理模块（含子模块）给更换掉，或者新增一个。
这里往往是业务上线后，最经常变更的点。有一个术语，叫做：开闭原则。对扩展开放，对修改关闭。
上述的业务框架图里面，从变更角度而言，应该要重点保证的，就是开闭原则。而我们常说的设计模式，很大程度上，也是为此而生的。
设计模式本身并不是什么技术原理。它只是借用了变成语言的特性，比如继承/派生等，在业务需要的时候，顺利切开修改的口子，方便程序员员快速完成工作。
案例思考
好比你在搭建一个运输系统。
刚开始的时候，需求很简单。
后来，需要新增火车运输。我们就得思考，运输方式上，是不是需要开一个接口，方便后续新增运输工具的时候，通过客户端自己选择实现类型就可以了。这个时候，工厂模式就派上用场了。
再后来，装货方式变复杂了，需要考虑什么货要装，什么货不装了。这时候的装货模块，是不是就可以考虑模板方式，或者责任链模式了？
设计模式就是这么简单，也比较抽象。我的理解，其实就是不断追求代码模块优化的精神。在业务变更中，不断进一步去思考更多的可能。
To do
后续做啥呢？其实学完之后，应该做的，就是不断练习一些实际的案例，教程案例还是太浅了，通过一些更实际的案例，去体会设计模式的妙处。