有些刚学 Java 的新人，特别喜欢用设计模式。他们觉得设计模式听起来很高级，好像用了就能让程序变得很厉害。但其实，如果没有经验，乱用设计模式，会让以后维护的人更辛苦。
一、乱用设计模式，让事情变得更麻烦
有一个刚学 Java 的小伙伴，他写一个很普通的“计算价格”的功能。本来这个功能很简单，只要输入商品价格，再加上一点税，最后算出总价就行了。其实两三个方法就能解决。
结果他觉得这样太“普通”，不够“专业”。于是他开始想各种设计模式。他想：“我是不是可以用工厂模式？是不是可以用策略模式？是不是可以用装饰者模式？这样看起来就像一个大工程师了。”
最后，他写出来的代码是这样：
- 先有一个工厂，用来创建不同的价格计算策略
- 再有不同的策略类，比如“正常价策略”“节日价策略”“会员价策略”
- 最后还有一个装饰类，说什么可以再额外加税、加服务费
听起来好像很厉害，但其实公司根本没有那么复杂的需求。所有商品都是一样的算法，根本不需要策略，也不需要工厂，更不需要装饰者。
后来来了一个负责维护的人，他想简单改一下税率，结果找了半天才找到放税率的地方。因为税率藏在一个“加税装饰器”里面，还被别人包装了一层。他改完之后，又发现有两个类也写了类似的逻辑，必须一起改，不然会算错。
最后，大家都觉得这段代码像是迷宫一样麻烦。其实完全可以用简单写法，两分钟改完的事，结果花了半天。
这个事情告诉我们：
不用为了显得专业，就去乱用设计模式。设计模式不是装饰品，而是工具。需要的时候再用，不需要的时候越简单越好。
二、再举一个例子：不该用观察者模式的时候硬要用
有一次，公司做一个很小的功能，就是“当用户下单之后，发送一条通知给管理员”。就这么简单一件事。
正常做法就是：
在下单完成的代码里，加一句“发送通知”就结束了。
这个新人又觉得这样太不“设计模式”了。他一想：“观察者模式好像可以用啊！下单是事件，通知是观察者。这样我写出来就好像很高级！”
于是他做了以下事情：
- 弄了一个“订单事件中心”
- 下单之后不是直接发通知，而是先“发布事件”
- 再写一个“管理员通知观察者”去监听这个事件
- 还写了一个注册监听器的工厂，说什么“以后可能有更多观察者”
最后，加一个小功能要绕五六个类。
更糟的是，后来管理员通知方式要改一下，比如换新的短信接口。结果工程师为了找到发送通知的代码，要从事件中心找到监听器，从监听器找处理逻辑，然后再去找工厂绑定关系。看得头都大了。
其实这个功能永远只有一件事：
有人下单 → 发通知
一句话。
结果新人写成了一大堆像蜘蛛网一样的结构，维护起来比原来困难十倍。
三、总结：设计模式不是用得越多越好
- 设计模式不是用来炫耀的。
- 能不用模式就不用模式，能简单就简单。
- 先把功能写清楚，再看需不需要设计模式。
- 没有经验的人最容易为了“好看”而把代码写复杂。
设计模式本来是为了让代码更好维护，但如果用错场合，就会变成负担。新人最常犯的错误，就是把一个简单功能写成像大工程一样，看起来花里胡哨，但一点都不好维护。
所以真正厉害的工程师，不是写复杂的代码，而是写谁都能看懂的代码。越简单越厉害。
会写代码是很重要的，但会写“简单且合适”的代码更重要。
