分享是最有效的学习方式。
_{博客：https://blog.ktdaddy.com/}

_{老猫的设计模式专栏已经偷偷发车了。不甘愿做crud boy？看了好几遍的设计模式还记不住？那就不要刻意记了，跟上老猫的步伐，在一个个有趣的职场故事中领悟设计模式的精髓。还等什么？赶紧上车吧}

# 故事

之前让小猫梳理的业务流程以及代码流程基本已经梳理完毕【系统梳理大法&代码梳理大法】。从代码侧而言也搞清楚了系统臃肿的原因【违背设计原则】。小猫逐渐步入正轨，他决定从一些简单的业务场景入手，开始着手优化系统代码。那么什么样的业务代码，动了之后影响最小呢？小猫看了看，打算就从泛滥创建的线程池着手吧，他打算用单例模式做一次重构。

在小猫接手的系统中，线程池的创建基本是想在哪个类用多线程就在那个类中直接创建。所以基本上很多service服务类中都有创建线程池的影子。那么他又该如何应对呢？

# 写在前面

遇到上述小猫的这种情况，我们的思路是采用单例模式进行提取公共线程池执行器，然后根据不同的业务类型使用工厂模式进行分类管理。

接下来，我们就单例模式开始吧。

# 故事

这段时间以来，小猫按照之前的系统梳理方案【系统梳理大法&代码梳理大法】一直在整理着文档。

系统中涉及的业务以及模型也基本了然于胸，但是这代码写的真的是...

小猫也终于知道了为什么每天都有客诉，为什么每天都要去调用curl语句去订正生产的数据，为什么每天都在Hotfix...

整理了一下，大概出于这些原因，业务流程复杂暂且不议，光从技术角度来看，整个代码体系臃肿不堪，出问题之后定位困难，后面接手的几任开发为了解决问题都是“曲线救国”，不从正面去解决问题，为了解决一时的客诉问题而去解决问题，于是定义了各种新的修复流程去解决问题，这么一来，软件系统“无序”总量一直在增加，整个系统体系其实在初版之后就已经在“腐烂”了，如此？且抛开运维稳定性不谈，就系统本身稳定性而言，能好？

所以那两次事故还真不能怪小猫【事故1,事故2】

整个系统，除了堆业务还是堆业务，但凡有点软件设计原则，系统也不会写成这样了。

# 故事

小猫的风波已经过去了，这几天，小猫在安安心心地撸着系统现状方案，准备着下次月会的分享。

这天，原本静谧而又和谐的办公室却被开放平台老六抱怨声打破了。

“不改，别给我打电话了！说几遍都没用。这是一个研发的底线.....”

没过一会，产品老汪担心老六对其"对脸开大"，孙子似地提着杯咖啡找到了老六。老汪是明事理的产品经理，为人处事儿这方面没得说。

“这事儿，我也为难，兄弟，帮帮忙，来喝杯咖啡解解乏。我也知道这种客户很难搞，但是我们是乙方，没办法，这年头大环境摆在这里，赚钱不容易，大家互相体谅一下。”

老六接过老汪的咖啡，气呼呼地抿了一口。