继续上一篇博文《SOA——面向服务的体系架构》，这次主要向大家阐述面向对象和面向服务的关系，请大家多提宝贵意见！
OO（ObjectOriented，面向对象），用一张图表示OO进行系统开发的特性：
SO（Service-Oriented，面向服务），用一张图表示SO系统开发与运行的特性：
通过这两图的对比，如果抽象一点来说的话，这两张图其实都是一样的，运用同一种思想：通过某种形式，关联颗粒。如果用微观和宏观来说，OO是微观的，SO是宏观的。不追求细节的话，可以说，两者都是抽象出具体形式（对象，服务），然后根据某种协议关联起来，组成一个完整的系统。
SO和OO都属于系统在软件模型设计中的一种映射，不存在谁好谁坏的情况，并且这两者是可以共存的，我们的系统中既可以有对象的存在，方便我们解耦，分组做系统，也可以有服务的存在，将系统中各个零件通过消息组合在一起，应于企业服务。
举个例子来说，一个公司做软件，以每个服务包为单位做，每个服务包代表一种功能，在服务包中，采用面向对象（OO）的思想，利用类来编程和解耦，而一个公司的系统要跑起来的时候，就必须要所有服务包，或者一些服务包联合起来才能够跑通，这个时候就需要采用面向服务（SO）的架构，用消息将必要的服务包联系起来，以保证系统的正常运转。而其他的一些非必须服务包，可以延后再上线，只需要遵守接口协议，就可以随时的加入到整个系统的运营里。讲到这里大家可能对OO和SO有了一定的理解了，OO更加微观，细节参与到了系统的编程中，而SO更加宏观，粗粒度的整合系统。
为了更加便于我们了解SO，下面我们来阐述一下SO的基本原则：边界强制性、自制性、契约性以及Policy-based兼容性。
边界强制性——在SO系统中，跨国每个服务的边界去调用是需要成本的，而在OO的分布式系统中，我们可以很容易的调用远程对象，很有可能导致远程对象被过度调用；
自制性——在SO系统中，每个服务的内部都是自制的，即每个服务的升级，部署和修改对整个系统的影响是很小的，而在OO的分布式系统中，对象库的升级，部署和修改是以原子级别为单位的，由于耦合性过高，而且又没有SO的边界强制性，很大可能就会导致系统被重新建立（大家可以回想一下，是重新写一个系统容易，还是大范围优化一个系统容易？）；
契约性——在SO系统中，服务之间通过议定的纲要来传递数据，通过契约来特定化行为，也就是说服务对外交换信息的时候，仅仅需要告知“我能够做什么”或者“我仅能够做哪些我已经声明过的事情”，根据自身的能力来暴露数据和契约；而OO则要求整个系统类型的同一化，而这个同一化的过程需要通过类型和类来恒定。
Policy-based兼容性——Policy把服务与交互之间的约束抽象了出来。理解，基于某一种协议。
综上，SO最大的好处就是松耦合，使我们的系统有了弹性和稳定性，我们完全能够在架构系统的时候，基于一个准确的前提和一套简单的规则，自由发挥我们技术。
ps：SO与SOA有什么关系？我的理解：SO更倾向于一种思想，而SOA是运用SO这种思想的软件系统架构。
本文主要参考《对比面向对象和面向服务》这篇博文，感谢作者的提供，在本篇文章中，我也加入了一些自己的思考，如有做的不好的地方，欢迎指出！