学步园

　　在面向对象技术中，基本范例被改变为允许关系的分离。图1显示了面向对象技术的范式，在它里面程序被分成叫做对象（object）的更小的片段。每个对象都包含了系统的一些数据，并且程序封装了这些数据。换句话说，只有通过使用与该数据直接相关的程序才能访问这些数据。通过这种方法，系统被分离成独立改变的模块。数据表现的任何改变仅仅影响封装该数据的直接的对象。

　　对象使用消息彼此通讯。消息可能影响状态——换句话说就是改变数据——但是只能通过与本地数据密切相关的封装了的过程来改变它。对于小程序，对象范式对于隔离改变来说是有效的。但是，这个范式对于所有可能的使用情形来说并不是完美的。

　　现在面向对象技术已经被广泛地使用了。一般来说程序上的技术来自于学术界，但是面向对象技术事实上来自于商业组织。实际上面向对象技术有很多有趣的渊源，甚至于可以追溯到计算机科学的开端。现在对象技术是占有统治地位的商业软件范式。事实上每个软件生产商都提供了对象技术的解决方案，并一起提供了组件的下部构造，允许不同软件环境中的软件厂商之间交互操作。

　　面向对象的架构

　　对于主要的软件开发从业者来说，面向对象是缺乏软件架构方法的。在面向对象的方法和文化中，这种缺乏在很多方面都有表现。从通常被当作原始来源的OO（面向对象）思考、设计面向对象软件【Wirfs-Brock 1990】开始，已经有了软件架构的概念，包括通过观察协作图（collaboration diagram，它需要一个章节才能讲清楚）发现子系统（subsystem）。在接下来的十年中，在面向对象方法学社团中几乎没有写出什么有关架构的东西。主要的OO方法学的书本中关于架构的章节都很少，它们都是Wirfs-Brock的架构概念的一些模糊的反映。

　　由于实际上几乎没有关于架构的专著，大多数OO从业者都只有最基础的架构指导。他们没有理由认为架构很重要。这种态度导致OO项目中很大的混乱，因为小组成员必须尽全力去管理那些并非为他们设计的OO方法的复杂性和可伸缩性。

　　一般而言，OO方法包含了成功的对象模型技巧，在这些模型中大多数分解对象最终被转换为编程对象。这种方法叫做基于模型（model-based）的方法。为了了解架构，认为每个分解对象都不可避免地成为编程对象是所有OO开发人员都需要克服的一个主要障碍。在架构模型中，特定对象表现约束而不是编程对象。它们可能会，也可能不会被转换成编程对象，这是由开发人员的自行的决定。

　　 OO也在其它一些微小的地方与架构矛盾，这与项目文化相关。OO鼓励项目小组平等，这样所有的决定都是民主的。在这样的项目中就没有架构的角色了，因为在开发小组的成员之间作出的决定的差别是很小的。

　　 OO鼓励开发中的“bad-is-better”思考方式，实际上这是一种与架构思想背离的哲学。使用bad-is-better思想的时候，任务实现的外部表现远远超过了可以维护的的内部结构的任何需求。换句话说，快速迭代的原型处理，以及对架构原理的无情的漠视对于OO开发来说是一种正常的、健康的环境。

　　数据库技术也朝对象的方向演化。数据库技术源于几个不同的模型。近些年，数据库的关系模型是最有影响力的。到最近，面向对象的数据库已经成为重要的技术市场，而联合了面向对象和关系概念的数据库也很平常。大多数主要的行业数据库，例如Oracle 9i和IBM的DB2数据库都包含了对象－关系能力。