OO设计

时间：2024-12-24 23:33:50

评OO设计

昨天在微博上看到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

评OO设计
摘要: 昨天在微博上看到InfoQ提供了一本新书《完美软件开发：方法与逻辑》的PDF迷你版，这本书的介绍吸引了我："这书是培养帅才的书。如果想成为一方悍将（比如：C++高手，Android高手），那这书是不太适合的；但如果想鸟瞰全局，运筹帷幄，带领团队攻城略地，那这书是很有参考价值的"。我重点看了第7章“完美设计和编码之解构”，应该说这是一本好书，但是对我来说总体上没有什么新的收获，作者对软件设计的理解和我两三年前比较类似。从书的内容看得出，作者受OO方法影响很大，我也经历过这个阶段，所以，今天想通过这篇博文谈谈我对OO方法的看法。阅读全文

posted @ 2013-11-26 11:19 Todd Wei 阅读(713) | 评论 (4) 编辑

程序的本质复杂性和元语言抽象
摘要: 程序的复杂性包含了本质复杂性和非本质复杂性两个方面，前者即为逻辑，后者即为控制。代码优化的极限是由逻辑决定的，逻辑和控制本应是正交的两个维度，但多数程序中二者却耦合在一起降低了程序的可读性。组件复用和GoF设计模式都不是解决这一问题的有效途径，唯有元语言抽象能彻底地将逻辑和控制解耦，使得程序简洁、优雅、易理解、易维护。阅读全文

posted @ 2013-10-28 17:09 Todd Wei 阅读(1284) | 评论 (11) 编辑

需求变化与IoC
摘要: 要不被客户牵着鼻子走，需要自己有很强的设计能力，反过来让客户跟着你的设计来满足你的要求。这本质上就是软件设计中的控制反转(IoC)思想。IoC是每一个初级程序员向高级进阶所需要了解的最重要的设计思想。知道IoC概念的程序员不在少数，但不少人对于IoC的理解仅仅停留在通过依赖注入实现解耦这个层面。实际上，IoC的应用不仅包括解耦，它还是框架的基本原理，在非计算机领域，IoC也是无处不在。阅读全文

posted @ 2012-03-24 17:55 Todd Wei 阅读(5284) | 评论 (20) 编辑

MVCC思想在分布式系统中的应用
摘要: 本文介绍了一种基于多版本并发控制（MVCC）思想的Conditional Update解决分布式系统并发控制问题的方法。和基于悲观锁的方法相比，该方法避免了大粒度和长时间的锁定，能更好地适应对读的响应速度和并发性要求高的场景。阅读全文

posted @ 2012-03-13 07:35 Todd Wei 阅读(2582) | 评论 (6) 编辑

海量用户积分排名算法探讨
摘要: 问题：为2亿用户规模的网站设计一种算法，在每次用户登录时显示其当前积分排名。本文介绍了一种树形分区设计，它具有几种优点：1. 分区结构稳定，不受积分分布影响；2. 每次查询或更新的复杂度为积分最大值的log(n)级别，且与用户规模无关，可以应对海量规模；3. 不依赖于SQL，容易改造为NoSQL等其他存储方式。阅读全文

posted @ 2012-03-01 10:05 Todd Wei 阅读(12536) | 评论 (53) 编辑

理解HTTP幂等性
摘要: 在数学中，幂等性是指N次变换与1次变换的结果相同。本文介绍了：1.分布式系统中幂等性的概念；2.用幂等设计代替分布式事务的方法；3.HTTP主要方法的语义和幂等性。阅读全文

posted @ 2011-06-04 20:51 Todd Wei 阅读(10604) | 评论 (20) 编辑

系统的层次性与单一职责原则
摘要: 职责层次性的背后是需求层次性，那么需求层次性又是哪里来的呢？需求层次性来源于设计！对于汽车的用户来讲，他的需求是汽车整体这个层次的，至于汽车部件的设计则不属于他所关心的范畴。而发动机、轮胎等需求来源于汽车设计者对汽车结构的设计，这就是说为满足高层系统需求所进行的设计产生了子系统的需求，而子系统的需求又进一步产生了子子系统的设计，呈现出了设计层次性。需求=>设计=>需求=>设计…，需求和设计就像鸡生蛋，蛋生鸡一样层层地细化，我们称这种设计方式为职责驱动设计。阅读全文

posted @ 2010-09-11 14:27 Todd Wei 阅读(1604) | 评论 (13) 编辑

系统的维次与层次
摘要: 目前社区流行一种通过剖析底层机制来分析事物的方法。剖析底层机制本身并没有错，只是千万不要把底层机制视为事物的全部。按系统多维与多层次的观点，正如把类图画得再完美也不过是程序的静态结构特征，程序的动态特征还需要序列图等来体现；底层机制属于实现维，而接口规范维是与之正交的。所以，单纯的底层机制剖析虽然貌似深入，其实犹如“盲人摸象”只执一端而已。阅读全文

posted @ 2010-07-11 00:25 Todd Wei 阅读(1164) | 评论 (1) 编辑

REST构架风格介绍之二：CRUD
摘要: REST是以资源为核心的，没有服务的概念，这的确让人怀疑REST能否像ORB或SOA一样支持复杂的应用？REST和以数据为核心的关系数据库是类似的。数据和资源本质上都是状态，对状态的操作CRUD少一个不行，多一个多余。因此，REST也采用CRUD四种标准操作，分别对应于HTTP协议的POST/GET/PUT/DELETE方法。阅读全文

posted @ 2009-05-09 09:11 Todd Wei 阅读(2106) | 评论 (4) 编辑

REST构架风格介绍之一：状态表述转移
摘要: REST(Representational State Transfer)是HTTP协议的作者Roy Fielding博士在其博士论文中提出的一种互联网应用构架风格。与以远程对象为核心的ORB和以服务为核心的SOA相比，以资源为核心的REST让我们从崭新的视角审视互联网应用。REST为互联网应用量身定做的简洁模型、与HTTP协议的完美结合、构架的高伸缩性，为互联网应用构架设计和异构系统集成设计带来了一股清新的空气。阅读全文

posted @ 2009-05-08 01:38 Todd Wei 阅读(3860) | 评论 (21) 编辑

3层构架.NET还缺点儿什么？
摘要: 经历了一个3层构建的.NET企业级开发项目以后，对比J2EE的开发经验，感觉.NET在3层构架里面缺了点儿什么东西。简单说来，是缺乏业务层的应用规范（EJB）和应用服务器（JBoss，WebLogic）。阅读全文

posted @ 2008-10-12 12:04 Todd Wei 阅读(3255) | 评论 (20) 编辑

分类: architecture

相关文章