写了十年代码，面向对象还是一知半解，这也不能全怪你 _面向对象

文章插图

一、先说几个现象：

1.1
我曾经的团队中的几位优秀的架构师，写框架代码写的很不错的那种。他们为什么能写出好代码？为什么能做出复杂系统的设计？他们自己好像也不能说出个所以然来。我把这称之为意识流。（也就是大概是凭经验，靠感觉）并且，这种凭经验的说法也被不少DDD的专家大佬用来回答如何掌握领域建模能力上。

1.2
或者你也有一种感觉，你知道一些好的设计原则和模式，但是你不会用。另外一种感觉就是UML的图你都会画，但是如果让你从0开始设计一套系统，你还是不知道如何开始。

1.3
只能凭经验这种说法，对于我一个管理者来说。它意味着不可快速培养，无法规模化；只能任由其自由生长，通过一个又一个项目来加强和验证一个人是否拥有良好的设计能力，是否有架构师的潜质。我始终无法接受这个结果。虽然之前我也是一个经验和感觉型选手。

二、转机

2.1
转机的上半部分来自于我看了一书关于架构的神书《系统加构——复杂系统的产品设计与开发》豆瓣评分达 9分。通常在8分以上就是值得一读的书了， 9分的书读懂一本对某件事情的看法可能就会发生一些根本性的改观。这本书确实很难懂，至少我强行安利给了我身边的很多人，并且还组织过一段时间的读书分享小组。这本书的作者对于架构的本质，以及如何来做架构是非常深的。虽然这本书的难懂确实让很多人放弃了，但我始终认为坚持看完3遍以上你对架构这件事情会产生很大的改观。

【写了十年代码，面向对象还是一知半解，这也不能全怪你】2.2
上面那本书虽然把架构的本质讲清楚了，但是并没有降低多少做架构的复杂度。直到我通过这种书里面用的概念建模语言OPM 找到了另一本书《基于模型的系统工程——综合运用OPM与SysML》，怎么说呢，我当时也是震惊的。因为这里面是这么说的：

功能是整个模型由此逐渐演变的种子。这条原理可能违反直觉。因为许多工程师倾向于从结构——对象、系统包括的实体，而不是功能开始建模。

也就是说它是从找到关键过程开始的，这有一种好像回到面向过程的方法里面去了。要知道在《面向对象分析与设计》里面，格雷迪大佬明确地表示这种结构化的设计过程是不可取的。

2.3
以公交车载客为例，如果是用面向对象的方式描述，就会把整个系统分为公交车，司机，乘客，车站等，然后分析它们在整个系统运作中的互动关系，关注的焦点是对象；而如果是面向过程，则会把整个从过程拆解为“开始跑路线-载客-启动-到站” ，关注的焦点是过程。

面向对象的建模（当然，这是静态结构的建模，如果要对动态行为进行建模，我们还需要一个时序图来表示）