25 | 设计模式：每一种都是一个特定问题的解决方案

从为了设计而设计，到为了解决问题而设计，这几乎是成熟程序员的必由之路。学费公司出，这也是我们这个行业的必由之路😂

曾经买过一本《大话设计模式》，每晚必挑灯夜读之。然而现在，心中已无模式，只有原则。

看老师的专栏太难受了！思考的乐趣与设计的美感，每每反思自己的代码，总感觉心痒痒的，恨不得把所有相关代码都看一遍，了解各种框架，各种中间件是怎么去做的，去实践的。

之前就曾经叹服于一些设计模式，比如工厂模式，到了动态语言中会有那么简洁的实现，简洁到甚至感觉不到模式的存在，原来设计模式只是为了通往更好设计的解决方案。当语言的本身掣肘随着发展而被祛除，设计模式也就完成了它们的使命。 当一些设计模式最终更好的开发语汇所替换掉，模式背后的设计原则，将会永远存在下去。 这就是郑老师所讲的根基与枝叶的关系吧。

平时使用过单例，策略，观察者等模式，从一开始纠结于如何按照规定编写代码，到后面已经脱离了编码层面的使用，我总结出，学习设计模式，学习的不是如何编写代码，而是一种软件设计思想，比如什么场景使用策略模式，什么场景使用观察者模式，甚至是已经完全不体现在代码层面，而是对系统的功能的设计，对业务场景的梳理。所以我觉得设计模式最后的样子，是一种解决业务，设计软件的模型。

Template Method 这个模式用得比较多，因为只需要将不同的部分封装到子类，场景比较清晰。其他的设计模式就用得比较少。 这个专栏给出的原则挺多，准备一个一个来践行，因为一下子体会到全部有点难，得一边写代码一边对照思考，慢慢改变自己的编程思想。

跟独孤九剑一个道理,剑式就那么九个,怎么解决敌人就看具体是什么问题,在这九式的指导下见招拆招就可以

设计模式反复看过很多次，可能和我做Bs架构的管理系统有关，只用过单例，消费者，生产者，然后是简单工厂。其他没用过

那个《面向模式的软件架构》实在是太狠了，居然有 5 卷，并且还得了 Jolt 大奖。 这篇专栏可以作为学习设计模式的一个开篇词。 之前也学习过 23 中设计模式，但是在写程序的时候其实用的并不多，时间长了，连 23 个模式的名字都记不全。 有时候按照 SOLID 原则去重构一些代码，总感觉好像是对应了某一个设计模式，但是又似是而非，需要到隔壁专栏复习一下设计模式。 “看眼看模式”部分，讲到程序设计语言的发展使得一些模式有了新的写法，我有点好奇，在业界究竟有多少公司能够跟进语言的演变。

感觉悟了；如果没有理解分离关注点和dip；很可能就在业务处理流程中直接调用 UserCollectorChannel的send方法了；都不会想到抽象出usersend接口。