首页 > 代码库 > OO (VS) SO

OO (VS) SO

          继续上一篇博文《SOA——面向服务的体系架构》,这次主要向大家阐述面向对象和面向服务的关系,请大家多提宝贵意见!


OO(ObjectOriented,面向对象),用一张图表示OO进行系统开发的特性:

 

             

 

SOService-Oriented,面向服务),用一张图表示SO系统开发与运行的特性:

                   

                           

        通过这两图的对比,如果抽象一点来说的话,这两张图其实都是一样的,运用同一种思想:通过某种形式,关联颗粒。如果用微观和宏观来说,OO是微观的,SO是宏观的。不追求细节的话,可以说,两者都是抽象出具体形式(对象,服务),然后根据某种协议关联起来,组成一个完整的系统。

 

         SOOO都属于系统在软件模型设计中的一种映射,不存在谁好谁坏的情况,并且这两者是可以共存的,我们的系统中既可以有对象的存在,方便我们解耦,分组做系统,也可以有服务的存在,将系统中各个零件通过消息组合在一起,应于企业服务。


         举个例子来说,一个公司做软件,以每个服务包为单位做,每个服务包代表一种功能,在服务包中,采用面向对象(OO)的思想,利用类来编程和解耦,而一个公司的系统要跑起来的时候,就必须要所有服务包,或者一些服务包联合起来才能够跑通,这个时候就需要采用面向服务(SO)的架构,用消息将必要的服务包联系起来,以保证系统的正常运转。而其他的一些非必须服务包,可以延后再上线,只需要遵守接口协议,就可以随时的加入到整个系统的运营里。讲到这里大家可能对OOSO有了一定的理解了,OO更加微观,细节参与到了系统的编程中,而SO更加宏观,粗粒度的整合系统。

 

        为了更加便于我们了解SO,下面我们来阐述一下SO的基本原则:边界强制性、自制性、契约性以及Policy-based兼容性

 

边界强制性——在SO系统中,跨国每个服务的边界去调用是需要成本的,而在OO的分布式系统中,我们可以很容易的调用远程对象,很有可能导致远程对象被过度调用;

 

自制性——在SO系统中,每个服务的内部都是自制的,即每个服务的升级,部署和修改对整个系统的影响是很小的,而在OO的分布式系统中,对象库的升级,部署和修改是以原子级别为单位的,由于耦合性过高,而且又没有SO的边界强制性,很大可能就会导致系统被重新建立(大家可以回想一下,是重新写一个系统容易,还是大范围优化一个系统容易?);

 

契约性——在SO系统中,服务之间通过议定的纲要来传递数据,通过契约来特定化行为,也就是说服务对外交换信息的时候,仅仅需要告知“我能够做什么”或者“我仅能够做哪些我已经声明过的事情”,根据自身的能力来暴露数据和契约;而OO则要求整个系统类型的同一化,而这个同一化的过程需要通过类型和类来恒定。

 

Policy-based兼容性——Policy把服务与交互之间的约束抽象了出来。理解,基于某一种协议。

 

        综上,SO最大的好处就是松耦合,使我们的系统有了弹性和稳定性,我们完全能够在架构系统的时候,基于一个准确的前提和一套简单的规则,自由发挥我们技术。

 

         psSOSOA有什么关系?我的理解:SO更倾向于一种思想,而SOA是运用SO这种思想的软件系统架构。

本文主要参考《对比面向对象和面向服务》这篇博文,感谢作者的提供,在本篇文章中,我也加入了一些自己的思考,如有做的不好的地方,欢迎指出!