对比面向对象和面向服务

Metaphor: bridge to the unknown. – Object thinking

就像Object thinking那本书中所说的那样，“比喻：通向未知的桥梁”，同样，我们在学习新技术和新名词的时候也可以通过打比喻，作对比来达到知晓的目的。那么比喻为什么能够帮助我们呢？那是因为，人们总对于自己熟悉的事物比较能够理解。通过比喻和对比，在新事物与旧事物之间建立快速联系，就能够帮助我们了解新事物的特征。

好了，本文的读者不需要太多的技术功底，只需曾经使用OOD进行过系统设计过即可，当然，如果你对OOP, OOA和Web Service有所了解，那就更好了；如果你已经对SO了解，那么不必读下去了。

我们总是在改变，我们的世界如此，我们的系统也是如此。那么当SO出现在我们的世界里，我们就会问了，”OO被淘汰了吗？”，“SO能够解决OO解决不了的问题吗？”

如果第一个问题答案为是，而第二个问题答案为否，那么SO就没有任何存在的必要了，换句话说，我也不在这给大家介绍了。

好，“OO被淘汰了吗？”首先我们来看一个图

这个图很清楚地表明了我们使用OO进行系统开发的特征，也就是说，其实我们的系统就是通过将不同的对象进行引用而形成的。

好，我们再来看另一个图

那么有人会说了，SO不过是OO的一个扩展吧？

如果说系统是真理的话，那么OO和SO是系统在设计世界中不同的模型折射，因为我们都知道，真理是立体的，它有不同的呈现方式，我们每个人看到它的不同的方面。

好像目前为止，我没有对上述问题做出任何正面的回答，其实答案已经有了，那就是“否”，OO没有被淘汰，我们只是对于系统的认知更进了一步，我们看到了系统的另一面。SO也不是对于OO的扩展，因为就好比宏观经济学和微观经济学之间的关系，你不能说前者是对于后者的抽象，而后者是对于前者的扩展一样。

不同的人看同一个事物，会有不同的观点和印象，对于一个实现了的系统而言，程序员因为看到自己写的代码只不过是些贴上标签的C#类，因此他们坚持认为这是OO; 架构师会说，我设计的是符合SOA所有的特征的，因此我坚持认为这是SO。这也就是现在对于SO的认知如此的模糊的原因。

通过这两张图我们可以清楚地知道，SO和OO都是系统的在软件模型设计中的一个影射，因此不存在谁淘汰谁的问题，他们是可以共存的，我们的系统中既有对象的存在，也有服务的存在，面向什么的设计，编程都是一个分析，实现者的哲学观的问题。

好了，我们知道OO不会被淘汰，后果不严重，大家很欣慰。

那么，“SO能够解决OO解决不了的问题吗？”

对于这个问题，让我们来了解一下SO的基本原则，这就是边界强制性、自制性、契约性以及Policy-based兼容性。接下来逐一解释。

边界强制性

在服务的世界中，每个服务之间的边界是清晰的，并且是强制的。对于一个系统，你一眼看过去，有多少个服务在那里都很清楚。而且，服务边界是通过消息来勾连的。我们可以把消息看成水，把服务看成鱼，把系统看成鱼缸。每条鱼都是独立存在的，通过水来组合成一个鱼缸。

在SO系统中，跨过每个服务的边界进行调用是有成本的，我们会很清楚；但是在OO的分布式系统中，我们很容易把一个远程的对象当作本地对象来对待，很可能导致远程对象被过度使用。这就好比你到超市最好列个购物清单，以免超过预算；而到一般的便利店则不必担心这个问题。

自制性

每个服务内部都是自制的。也就是说，系统中的某个服务被部署，升级和修改，都不会影响到整个系统被重新建立。

而在OO建立的分布式系统中，我们可以知道，某个对象库往往是以原子级别单位被部署，升级和修改的，那么由于耦合的程度高，并且对象库之间的调用没有明确的边界强制性，就会导致整个系统需要重新建立。

大家有多少次觉得，维护一个现有的系统比重新写一个同样的系统要来得困难呢？

契约性

服务之间通过议定的纲要来传递数据通过契约来特定化行为。那么OO的世界里呢？那是通过类型和类来传递的。

某个服务对外交换信息的时候，仅仅告诉别的服务，“我能够做到什么”，“我仅能够做那些我已经声明过的事情”；也就是说，服务是根据自身的能力来暴露数据和契约的。

OO则要求整个系统类型的同一化, 而这个同一化的过程是通过类型和类来恒定的。

Policy-based兼容性

Policy干了什么? 呵呵, 它抽象了一下。（记得C++沉思录中说过一句经典的话，那就是OO真正的威力在于抽象。）那么它抽象了什么？它把服务与交互之间的约束抽象了出来。难理解？这么想，举个例子，服务为什么能够和传统的Web服务交互？就是因为大家都基于相同的策略。

那么，SO又有些什么优势呢？

最大的好处就是系统松耦合，那就有了弹性和适应性。我们可以这么想，把SO想象成一个巨大的架构模式，它有一些规则，它把原有的在被反复使用的模式融合起来，让我们在架构系统的时候基于一个准确的大前提和一套简单的规则，而自由发挥。

现在可以来回答这个问题了，SO能够解决OO不能够解决的问题，从宏观上说，SO给与架构系统更简单的规则，大家都知道，简单意味着更不容易出错，而OO给与我们过于自由的尺度，这也是为什么现有多数系统糟糕、杂乱的原因；从微观上说，SO甚至比OO提供给我们更多的设计自由，我们能够将现存所有的技术，基础结构统统放到我们的方案中，而不必关注技术和基础结构的实现细节。

对比面向对象和面向服务相关推荐

面向对象，面向服务（转）
面向对象,面向服务转自(http://www.cnblogs.com/rib06/archive/2007/05/23/756385.html) 关于这两个概念之间的联系.区别,在SOA提出之初就已 ...
面向对象，面向服务，面向组件三种编程模式有什么区别
三个数据后面都缺了一个词,分别是:"编程"."架构"和"开发"(或"软件工程"). 同时,不是"面向" ...
组件化、模块化、集中式、分布式、服务化、面向服务的架构、微服务架构
组件化.模块化.集中式.分布式.服务化.面向服务的架构.微服务架构最近最火的词是什么?那大概就是微服务(Microservice)了.最近也火的一踏糊涂的Docker.DevOps也都是围绕着微服务 ...
理论三：面向对象相比面向过程有哪些优势？面向过程真的过时了吗？
王争<设计模式之美>学习笔记文章目录理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗? 什么是面向过程编程与面向过程编程语言? 面向对象编程相比面向过程编程有哪些优势? 1 ...
我的WCF之旅（7）：面向服务架构（SOA）和面向对象编程（OOP）的结合——如何实现Service Contract的继承...
当今的IT领域,SOA已经成为了一个非常时髦的词,对SOA风靡的程度已经让很多人对SOA,对面向服务产生误解.其中很大一部分人甚至认为面向服务将是面向对象的终结,现在的面向对象将会被面向服务完全代替. ...
Atitit 面向对象编程（OOP）、面向组件编程（COP）、面向方面编程（AOP）和面向服务编程（SOP）的区别和联系...
Atitit 面向对象编程(OOP).面向组件编程(COP).面向方面编程(AOP)和面向服务编程(SOP)的区别和联系 1. 面向组件编程(COP) 所以,组件比起对象来的进步就在于通用的规范的引入 ...
面向对象编程、面向服务架构、基于组件开发三种编程模式的区别和适用领域
面向对象编程(Object-Oreinted Programming) 是一种编程范式.指在设计程序时大量运用类实例对象的方式.OOP一旦在项目中被运用,就成了时刻要考虑的东西. 面向服务架构(Ser ...
面向对象编程（OOP）、面向组件编程（COP）、面向方面编程（AOP）和面向服务编程（SOP）
1.什么是面向对象编程(Object-Oriented Programming)? 面向对象编程(Object-Oriented Programming)简称OOP技术,是开发计算机应用程序的一种新方 ...
传统单体应用、SOA（面向服务）、微服务之间的对比
1.单体应用 MVC模式构建的单体应用适合项目初期,能够方便的进行开发,部署,测试.随着业务的增长与访问量的增加,单体应用存在的问题也会暴露出来. 单体应用的维护: 单体应用中,大部分逻辑部署在一个集 ...

对比面向对象和面向服务

对比面向对象和面向服务相关推荐

最新文章

热门文章