软件的复用最初是从函数库和类库开始的，这两种复用形式实际上都是白箱复用。到90年代，开始有人开发并出售真正的黑箱软件模块：框架（framework）和控件（control）。框架和控件往往还受平台和语言的限制，现在软件技术的新潮流是用SOAP作为传输介质的Web Service，它可以使软件模块脱离平台和语言的束缚，实现更高程度的复用。但是想一想，其实Web Service也是面向对象，只不过是把类与类之间的关联用XML来描述而已[Li, 02]。
在过去的十多年里，面向对象技术对软件行业起到了极大的推动作用。在可以预测的将来，它仍将是软件设计的主要技术——至少我看不到有什么技术可以取代它的。
二、OOD到底从哪儿来？
有很多人都认为：OOD是对结构化设计（Structured Design，SD）的扩展，其实这是不对的。OOD的软件设计观念和SD完全不同。SD注重的是数据结构和处理数据结构的过程。而在OOD中，过程和数据结构都被对象隐藏起来，两者几乎是互不相关的。不过，追根溯源，OOD和SD有着非常深的渊源。
1967年前后，OOD和SD 的概念几乎同时诞生，它们分别以不同的方式来表现数据结构和算法。当时，围绕着这两个概念，很多科学家写了大量的论文。其中，由Dijkstra和 Hoare两人所写的一些论文讲到了“恰当的程序控制结构”这个话题，声称goto语句是有害的，应该用顺序、循环、分支这三种控制结构来构成整个程序流程。这些概念发展构成了结构化程序设计方法；而由Ole-Johan Dahl所写的另一些论文则主要讨论编程语言中的单位划分，其中的一种程序单位就是类，它已经拥有了面向对象程序设计的主要特征。
这两种概念立刻就分道扬镳了。在结构化这边的历史大家都很熟悉：NATO会议采纳了Dijkstra的思想，整个软件产业都同意goto语句的确是有害的，结构化方法、瀑布模型从70年代开始大行其道。同时，无数的科学家和软件工程师也帮助结构化方法不断发展完善，其中有很多今天足以使我们振聋发聩的名字，例如Constantine、Yourdon、DeMarco和Dijkstra。有很长一段时间，整个世界都相信：结构化方法就是拯救软件工业的 “银弹”。当然，时间最后证明了一切。
而此时，面向对象则在研究和教育领域缓慢发展。结构化程序设计几乎可以应用于任何编程语言之上，而面向对象程序设计则需要语言的支持[1]，这也妨碍了面向对象技术的发展。实际上，在60年代后期，支持面向对象特性的语言只有Simula-67这一种。到70年代，施乐帕洛阿尔托研究中心（PARC）的 Alan Key等人又发明了另一种基于面向对象方法的语言，那就是大名鼎鼎的Smalltalk。但是，直到80年代中期，Smalltalk和另外几种面向对象语言仍然只停留在实验室里。
到90年代，OOD突然就风靡了整个软件行业，这绝对是软件开发史上的一次革命。不过，登高才能望远，新事物总是站在旧事物的基础之上的。70年代和80年代的设计方法揭示出许多有价值的概念，谁都不能也不敢忽视它们，OOD也一样。
三、OOD和传统方法有什么区别？
还记得结构化设计方法吗？程序被划分成许多个模块，这些模块被组织成一个树型结构。这棵树的根就是主模块，叶子就是工具模块和最低级的功能模块。同时，这棵树也表示调用结构：每个模块都调用自己的直接下级模块，并被自己的直接上级模块调用。
那么，哪个模块负责收集应用程序最重要的那些策略？当然是最顶端的那些。在底下的那些模块只管实现最小的细节，最顶端的模块关心规模最大的问题。所以，在这个体系结构中越靠上，概念的抽象层次就越高，也越接近问题领域；体系结构中位置越低，概念就越接近细节，与问题领域的关系就越少，而与解决方案领域的关系就越多。
但是，由于上方的模块需要调用下方的模块，所以这些上方的模块就依赖于下方的细节。换句话说，与问题领域相关的抽象要依赖于与问题领域无关的细节！这也就是说，当实现细节发生变化时，抽象也会受到影响。而且，如果我们想复用某一个抽象的话，就必须把它依赖的细节都一起拖过去。
而在OOD中，我们希望倒转这种依赖关系：我们创建的抽象不依赖于任何细节，而细节则高度依赖于上面的抽象。这种依赖关系的倒转正是OOD和传统技术之间根本的差异，也正是OOD思想的精华所在。
四、OOD步骤
细化重组类
细化和实现类间关系,明确其可见性
增加属性,指定属性的类型与可见性
分配职责,定义执行每个职责的方法
对消息驱动的系统,明确消息传递方式
利用设计模式进行局部设计
画出详细的类图与时序图
五、OOD设计过程中要展开的主要几项工作
（一）对象定义规格的求精过程