面向服务(SO)和面向对象(OO)的比较

 

本文译自Thomas Erl的《Service-Oriented Architecture: Concepts, Technology and Design》部分章节。

 

注意本节的标题是“面向服务和面向对象”，而不是“面向服务对面向对象”。这种区别是要强调这两种思想之间的关系不是竞争关系这一事实。

 

事实上，面向对象编程通常用于构建Web Services中应用逻辑的封装。然而，面向对象编程方法到底与面向服务方法有何根本的不同是值得去探索的，理解它们的不同有助于你将它们放在一起工作。

 

下面列出两种方法在设计方面的比较。（尽管使用“逻辑处理单元”术语在比较服务和对象会引起的混淆，然而面向服务是基于服务来设计，面向对象是以对象创建为中心。）

 

•          面向服务强调逻辑处理单元（服务）之间的松耦合。虽然面向对象支持可重用、松耦合的编程程序，但它主要基于预定义的依赖类，产生和逻辑处理单元（对象）的紧耦合。

 

•         面向服务鼓励粗粒度接口（服务描述），因此每个通讯单元（消息）都包含完成给定任务所需的尽可能多的信息。面向对象编程完全支持细粒度接口（APIs），因此通讯单元（RPC或本地API调用）能执行各种大小的任务。

 

•          面向服务期望逻辑处理单元（服务）的范围可以较大。面向对象中的逻辑处理单元（对象）趋向于在一定范围内更小和更加明确。

 

•          面向服务促进逻辑处理单元（服务）未知行为的创建，那是由智能通讯单元（消息）所引起的行为。面向对象鼓励逻辑处理和数据的绑定，产生非常智能的单元（对象）。

 

•          面向服务更多采用逻辑处理单元（服务）进行设计并进可能保持无状态。面向对象鼓励数据和逻辑的绑定，因此产生有状态单元（对象）。（然而，近来更多的基于组件的设计方法背离了这种趋势）

 

•          面向服务支持逻辑处理单元（服务）的松耦合组合。面向对象也支持组合但趋向于继承自逻辑处理单元（对象），那会导致依赖紧耦合。

 

上面从耦合度、接口粒度、关注点、状态等方面对面向服务和面向对象进行了比较。下面再对两种方法的设计原则进行比较。

 

当然，面向服务还欠缺很多面向对象已有的概念和理论。下表提供了一般的面向对象原则与已经讨论过的面向服务的原则的比较。 

 

面向服务原则	面向对象原则
服务的重用	面向对象大多数情况是创建可重用的类，模块化分解的面向对象原则是应用程序的设计方式。   相关的原则，如抽象，封装，接口和实现逻辑的分离。服务重用是这个目标的延续。
服务的契约	服务契约的需求和构建面向对象应用中的接口相类似。接口提供了一种提炼类描述的方法，这和WSDL 的定义非常相似。与SOA鼓励的“WSDL优先”方法一样，“接口优先”方法也被认为是面向对象的最佳实践。
服务的松耦合	尽管接口的创建一定程度上将类从类的使用者解耦，但耦合是面向服务从面向对象继承到的主要特性。   相对面向服务设计方法，继承和其他面向对象原则造成逻辑处理单元之间的紧耦合。
服务的抽象	面向对象的抽象原则要求一个类提供一个接口给外部世界，并通过这个接口来访问类。封装通过建立信息隐藏概念来支持这种方式，通过接口暴露的类内部的任何逻辑都不能被外部所访问。   服务抽象可以基本达到对象抽象和封装的程度。它的目标是隐藏服务的内部细节，因此只有服务契约是可以得到的，服务的请求者也只要关心服务契约。
服务的组合	面向对象支持关联的概念，如聚合和组合。在松耦合的上下文中，这些概念也被面向服务的方法支持。   例如，可用与组合成对象层次结构相同的方法来将可组合的服务装配成服务层次结构。
服务的自治	自治的特性在面向服务设计中比在面向对象方法中有更重要的作用。在面向服务中，通过利用服务间的松耦合关系，可以实现逻辑处理单元之间的独立性。   在面向对象设计中，跨对象引用和继承相关的依赖支持较低程度的对象级自治。
服务的无状态	由类结合和数据构成的对象天生就是有状态的。服务中提倡的无状态趋向于背离典型的面向对象设计。   尽管可以创建有状态服务和无状态对象，但无状态原则是面向服务中通常更加强调的。
服务的发现	设计一致的和自描述的类接口是另一个面向对象最佳实践，它能改进识别和区别逻辑处理单元方法。这些特性也允许类被更容易地发现。 可发现性是面向服务范例中强调的另一个原则。它鼓励服务契约的交互支持在设计和运行时的可发现性。

 

可以看到，面向对象和面向服务并非竞争者。面向服务显然在不少方面是以面向对象为基础，当前典型的面向服务的解决方案将由服务（遵循面向服务的原则）和面向对象的组件构成。在合理的设计中，每个原则都能被适当地处理并能相互补充。