结构化思维与面向对象思维

摘自Kanas.Net Blog

结构化思维是面向对象思维的基础。幻想中的一步登入OO的天空并无可能。面向对象的很多原则与结构化思维并无矛盾。真正对OO从理论到实践都透彻的人并不一定排斥结构化思维。

不要比较面向对象与结构化思维的得失。谈到得失就必须有一杆秤。可惜这个世界上没有这样一杆公平的秤。每个人的经历不同、背景不同、思维方式不同，评估的结果就千差万别。其实没有对错，只有针对每个具体人的有效和无效。前面所述，通过面向对象可以将一个复杂问题迅速简化，当我遇到问题时候，我的方法通常是三步走：第一步解决最小的简单模型；第二步解决复合的常规模型；第三步解决扩展的推广模型。这样的确可能比结构化编程费一些事情，但基于我的智力，没有办法一次解决，所以我这样选择是基于我个人的情况。

不要讨论面向对象的性能损失。比方说，很多人都认为基于托管代码的系统比基于原生代码的系统慢，但据ACM(美国计算机协会)1999年的调查报告，采用Java或者C/C++编写的系统，性能差异很小，而不同程序员间的差异却高达30倍！既然如此，为什么不把更多精力花费在代码间，而是讨论面向对象会给系统带来多大的性能损失呢？

不要讨论什么充血模型或者贫血模型。解决问题才是最高目标，何必在乎形式呢？既然连结构化思维都可以接受，为什么要排斥所谓的贫血模型呢？(实话说我个人非常排斥老马的某些观点，为什么要把一个灵活开放的东西搞得那么死板教条呢？)譬如，面向对象有一个原则是尽量采用chatty接口，创建许多简单方法。而在分布式编程中这个原则就成了灾难(你不得不多次连接调用)，所以分布式编程的原则是尽量采用chunky接口，把方法留给本地，这是典型的结构化思维。所以原则并不是一成不变的。

不要把责任推给你的上司、团队或者组织。不论你是一般程序员，还是团队负责人，每个人都是团队的重要成员，每个人都会对你正参与开发的系统、对团队产生同样的影响。如果你一直希望改变你目前的方式，那就需要产生额外的效果，令你的上司和团队成员支持你。如果他们不支持你，不是因为他本身的素质，而是因为你没有让他看到效果。除了你自己是可以控制的，团队中的任何人你都只能影响，而不能控制。要改变他们，不是靠说教，而是靠实实在在的绩效。检讨一下你自己，是不是自己在某一方面做得不够好？或者根本你的出发点或者目标就值得怀疑？我相信很多人在对项目质量的考评中，进度会放在比质量更优先的位置。事实上进度与质量并不矛盾。如果组织更注重进度指标或者甚至根本不注重质量指标，你可以在不影响进度的前提下，提升质量指标，一定会获得组织的肯定。然后你就会慢慢发现，其实进度和质量可以相互促进而不是相互冲突。