我们面临一个较为复杂的系统时，考虑使用面向对象将代码模块化。
一般来说，如果有较为成熟的方案，可以直接借鉴。比如 GUI 系统，层次化的抽象已经有比较固定的模式， MVC 命令模式等等。
另一方面 神书 GoF 提出的 23 种设计模式基本上满足我们实践中的大多数场景。
然而，我们面对新问题，比较陌生的问题时，一开始就翻 GoF 翻看哪种模式“更像”我们的问题，往往会摸不着头脑，甚至会把问题搞复杂，向错误方向行进
我一般的做法是先忘记设计模式，把问题定义清楚。
使用时序图把系统的运作梳理一遍
然后画出数据流向图，把输入输出定义清楚。
最后再考虑如何抽象。
1.设计通用的公共类，公共对象，可以先写出用例，客户将如何使用这个尚未实现的东西会更方面，秉持“尽量让客户简单处理，隐藏复杂细节，不做重复的事情”的原则；用例描述清楚之后，我们大概知道了公共类需要提供的接口是什么。
最复杂的细节将在何处处理，以及重复动作应当用什么样的封装办法去避免。
一般做到这里的时候，我们将会用到哪些模式基本上已有轮廓，公共的基类，最核心的API
- 写复杂系统类似，最开始，系统还没有出生的时候，最好要仔细考虑客户怎么使用它，从这个出发点推演这个系统和客户的交互，接口。
再审视数据流和核心的复杂性怎么处理，可以让维护成本最小。
最快实现和维护成本最小，我倾向后者，林肯有句名言
如果我想用八分钟砍一棵树，那我会用八小时去磨斧子
在系统最关键的部分花费时间是值得的，如果我们追求快速实现，除非面对的是一个前人解决过的问题，我们可以用最短的时间 copy 过来用在我们看中的地方，然而，如果是一个全新的问题，还是追求快速实现，毫无疑问会持续地增加大量的技术债务，在未来的某段时间，总得还。
新问题需要花时间去思考，定义，建模，而不是尽快给出解决方案。
日常工作中，几乎遇到的基础问题多数已有一些解决方案，但是上层业务又有其独特性，我们花一点时间思考一下是值得的，否则，为什么你的工作机器不能取代？
网友评论