优雅のJava（零）—— 面向问题的学习

文章导航

优雅のJava —— 前置知识 七大原则

优雅のJava（零）—— 面向问题的学习（本篇）

优雅のJava（一）—— 代码重复问题 模板方法 装饰器模式

优雅のJava（二）—— 优雅的单例是怎么实现的？

优雅のJava（三）—— 优雅的制造对象是怎么实现的？工厂模式

优雅のJava（四）—— 优雅的理解代理模式

优雅のJava（五）—— 优雅的观察对象与订阅信息 观察者模式 好莱坞原则

优雅のJava（六）—— 优雅的解决依赖问题？IOC模式 DI spring 循环依赖

… 还在持续更新

前言

说实话一直想学设计模式，感觉酷酷的，但问题是官方的定义不讲人话，而类似尚硅谷的教程，虽然已经是梳理得很开了，但是感觉学的还是有点死记硬背的味道，即，学一个新模式，敲一下代码，看一下优点，下一个，

然后自己写的时候还是选择综合征+畏畏缩缩担心代码不够好+最后写的自己都不知道是什么

最要命的是，模式多了开始晕，组合起来运用更加不可能，然后大佬们夸夸其谈将自己用了啥模式啥模式balabala，你只能装作自己听懂了然后尴尬而不失礼貌的微笑，生怕大佬瞧不起你。

我不装了，这么学和背课本差不多，就感觉是被动的接受但永远不能内化成自己的东西，如果，换个思路，我来针对某些问题，“创造”模式，有种主人翁的心理，而非被填充知识的鸭子，那又如何？带着这个思路，打算重新审视一下，设计模式。

这个我称为，面向问题的学习（Question Oriented Learning），接下来我们短暂的唠一下嗑，说一下设计模式的起源，然后进入本次文章的核心——模板方法。

设计模式的来源

历史来源就是，最早有哥们总结了建筑领域的253个模式，然后90年代，四人帮（GoF）站在前人的肩膀上，将前面那253用到了编程领域，然后写了那本书，专门为了解决面向对象设计开发的问题。
当然了，设计模式真正流行，我猜想是，来到IT行业，流水线生产，多人配合的时代，就好比服务端程序，有些人之前写PHP也行啊，你甚至还可以用c实现啊，为什么后面主流是java，因为应用场景错综复杂，需求变化多端，需要多人合作，这时代码的艺术体现出来了，有人开始琢磨怎么样才能让多人合作项目更加高效，估计就这么翻出来90年代还有个设计模式这种说法，用一下还挺好使，于是流传到今天。

什么是设计模式 design pattern

说白了 固定套路，那什么套路？用来解决一类问题的套路

比方说你写代码思考到，未来万一需求改变了，或者在原有基础上增加了，有没有优雅的方式能够高效更新代码的时候，这时如果你犯难了，说明你应对这类问题还没有套路，而如果用了相应的设计模式，相当于借助前人的思考成果，想出合适的解决方案，这就说明你学会了这一模式。

假设，你要是这次绞尽脑汁想出来个法子，瞎写，然后苟着苟着勉强达到设计目标，下次遇到同样的问题，又凉了，因为没有总结，那就是最低效的，也是没学会设计模式的结果。

讲完这些我们说定义：针对某一上下文环境中一个问题的常用 通用解决方案

这告诉我们什么？通解是有，但是个性化的运用就看本事了。

实际上发明设计模式的Gof也没有定死这模式的标准，后人在此基础上，如果发现相似儿常见的问题，在Gof设计模式上做了点变式，那当然也是ok，
可以说这是好事，时代在发展，只会使用几十年前的方法论应对现在的问题，恐怕心有余而力不足。