聊聊我对 设计模式 的想法吧

最近接触到越来越多的实用主义，今晚逛陈硕大佬的知乎又看到那么一个话题讨论。

先说一下我的观点，我保持中立哈哈哈哈哈哈。

不是啥两边倒哈，我觉得==应该具体问题具体分析，脱离了实际的辩论都是虾扯蛋==。

我说个故事吧，憋在我心里好久了。

在我做第一个后端项目的时候，是老师给我们的框架，我又自己找学长拿了他的项目，两者框架差不多，看样子是没怎么改了。

什么框架呢，很常见。说一下前置服务器，一个好好的前置服务器，拆分为：

Inaddress模块、
Sock模块
Accept模块
Epoll_base模块
Epoll模块

我当时就给整懵了，花了两天时间才捋清楚这些绕来绕去的，毕竟第一次嘛。

但是呢，捋清楚就完事儿了吗？当我们开发到后期的时候，进行测试，我们几个做服务端的组长是有群的，对，组长都是负责服务端，他们也都是沿用老师给的框架，没有改过。

测试结果：
1分钟，3K个连接；
6分钟，9K个连接；
30分钟，1W个连接。

这是刚开始比较慢的。

经过我们几天的调优，同时连接1W个客户端进来也要花小十分钟。可惜我是个极简主义者，那时候留下了不少记录博客，全让我清理了，不然这会儿就能贴出来做个证据了。

为了加快速度，什么办法我们都试过了，后来，我实在是忍不了了，那么多个模块对象，我在网上看到一份纯C的epoll前置服务器，直接扒拉下来一试，诶呦，1W连接30s！

我苦思冥想一晚上，越想越觉得是因为没有那么多弯弯绕，于是我干脆仿照那套模式，把我的前置服务器全都堆到一个模块里面去，从配置网络接口到accept，再到epoll管理，统统放到一个 run 函数里面去，构造一个对象之后直接run。

一测试，1W连接2s。平均1W连接6s。

虽然后来的项目中我又对前置服务器进行了切割，不过那是采用了责任链模式对epoll模块进行简化，其实是进一步的优化了性能。

设计模式，几十年前的东西了。当初我非常痴迷于设计模式，第一轮学完设计模式之后，写个代码都要想着能不能硬套它两个模式进去，一有机会就把单例拿出来摆一摆；
第二轮学设计模式，我终于有了点理智，把重点放在了第一轮忽略的 设计模式六大原则 上，此后，我看每个设计模式，都要去寻找其底层和这些原则契合的地方，以及适用场景；
第三轮学设计模式，我已经带着稍微有点规模的项目来了，取了责任链、中介、享元、装饰、观察、单例、门面等模式走；
第四轮学设计模式，我删掉了绝大部分的设计模式相关博客，前面每一轮学习我都有写一套博客，一套平均20篇，不过现在在我的博客里只能看到寥寥几篇《我用过的设计模式XXX》，以及几篇舍不得删觉得早晚用得上的模式。

江山代有才人出，各领风骚数百年。
技术是不断向前发展的，现在难道就没有出新的模式吗？

发布/订阅（其实也是观察者，或者说是观察者的变种吧）、ORM等。

不要被事物的表面现象所迷惑，我们要透过现象看本质。至少现在，我看设计模式，整套模式里面都透露出来两个字：合适。
抓住设计模式的思想，无形的模式比有形的模式更重要。有形的模式是前辈们总结出来的，难道我们就不能总结出自己的模式吗？思想不要被禁锢了。

思想嘛，六个原则其实我也没完全吃透，说说我的理解：

1、单一职责。这个职责就很难界定，在我看来，以前面那个例子，从打开网络端口，到accept，完全就是一件被称之为：建立网络连接 的事情。一个类足矣。

2、松耦合。高内聚就是上面那个了。松耦合是什么意思呢，就是类与类之间的关联系数要小。少继承，多组合，继承这条贼船，一上去就很难脱身了。
什么是我理解的关联系数呢？我有十个服务器，两两之间要通信，我是整个MQ呢，还是整个MQ呢，还是让它们自己两两连接啊？那以后我要再加服务器怎么办？

3、接口隔离原则。也就是门面模式啦，就比方说大部分粉丝朋友，想找我聊聊天嘛，通过CSDN的私信功能，或者评论区评论功能，这两个接口是CSDN开放的功能。那其他方式嘛，可给可不给的那就默认不给咯。

记住那句话，==具体问题具体分析，脱离了实际的辩论都是虾扯蛋==。