昨天在微博上看到InfoQ提供了一本新书《完美软件开发：方法与逻辑》的PDF迷你版，这本书的介绍吸引了我：

这书是培养帅才的书。如果想成为一方悍将（比如：C++高手，Android高手），那这书是不太适合的；但如果想鸟瞰全局，运筹帷幄，带领团队攻城略地，那这书是很有参考价值的。

我重点看了它的第7章“完美设计和编码之解构”，应该说这是一本好书，但是对我来说总体上没有什么新的收获，作者对软件设计的理解和我两三年前比较类似，而最近两年我对软件设计的理解发生了很大的变化。从书的内容看得出，作者受OO方法影响很大，我也经历过这个阶段，所以，今天想通过这篇博文谈谈我对OO方法的看法。

我喜欢从道、术、灵3个角度看技术。道是事物的本质，是事物的共同性，修道最简单，一点就通，只需要悟性；术是具体技术和应用，修术比较难，需要长期积累和实践；灵是创造性，并由此产生事物的差异性，修灵最难，无规律可言，但它是道和术到达一定程度的自然产物。这里只讨论道的范畴，即主要探讨设计的本质和共同性。

所谓本质就是“变化中的不变”，所谓抽象也就是找到这个“不变”。我用提取公因子来比喻，假设你只有6、9两个数，你提取的公因子可能是3，并把3当成本质，但是其实1是更本质的，这时被你忽略了；当你有2、6、9三个数的时候，你突然发现3还不够本质，原来1更本质。这是个比喻，我不追求准确，目的在于比喻视野和广度的重要性。你的视野越宽涉猎范围越广越容易找到更深层次的本质。反过来，要检验你找到的本质是不是足够深，也要放到尽量宽的范围去。

两三年以前，我主要从事企业级软件开发，也认真学习和研究过OO方法，包括OOP基础理论、GoF设计模式、S.O.L.I.D设计原则、契约式设计、IoC原理等等，应该说对于OO方法的理解也代表我当时的阶段性水平。近两三年，我涉猎范围更加广泛，现在我系统底层、中间件、服务器、桌面/移动应用、Web什么都做。现在让我再回头看OO，就像找最大公约数的例子，它显然不是那个我要找的1，在谈论设计之道时，我已经基本上没有兴趣再谈OO了，就像我两三年前没兴趣谈“指针使用”这样的非设计的本质问题。现在如果让我来谈设计之道，OO的影子几乎都找不到；相反，如果我看到别人在谈设计之道时还在大量地围绕OO相关的话题来讨论，即使某些思路和传统方法不同，我还是感觉作者的视野和深度有进一步提高的空间。

*s讲的“根本任务是指打造构成抽象软件实体的复杂概念结构”没错，但是不论是面向过程还是OO方法都不是这一思想的最好体现。许多人也认识到软件设计是一个多维度、多层次的抽象过程，但是问题不在于这一认识本身，而在于如何定义这些维度和层次。基本上，我所了解的熟悉OO方法的人都很难脱离OO带来的思维局限，比如，不少人熟背“设计首先要抽象”，但是当他具体做设计的时候，一上来就定义了几个接口，几个基类，永远跳不出这个圈子，这就是各种OO设计模式和设计原则的副作用，它让人们潜意识里面把真正意义的抽象建模和OO的抽象建模混在一起。

有人用切蛋糕比喻软件开发，要把蛋糕切成8份，在1维空间需要切7刀，2维空间需要4刀，3维空间只需要3刀。所以，关键的问题在于如何选取下刀的维度。在我看来，OO方法基本上都属于这个比喻中的2维，好像比最笨的方法高明一点，但是其实远远不够。OO作为一种范式它本身代表了一定的抽象维度，在切蛋糕的比喻中就是下刀的位置。这种方法恰好碰对了问题的时候也是有的，比如，如果问题是让你切成4块，这种方法就完美了。但是，OO的根本性问题在于它不是从问题本质出发，而是强行地把实体、实体间关系、继承、子类型等概念往问题上加。

我们在评价一个方法是不是好方法的时候一定要坚持价值判断，即这种方法带来的软件“开发量、可读性、可维护性、可扩展性、可测试性”和其他方法比怎么样？我对OO以及相关各种方法的评价是：有一定价值，但远远不够。

architecture