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