- 面向对象编程(Object-Oreinted Programming) 是一种编程范式。指在设计程序时大量运用类实例对象的方式。OOP一旦在项目中被运用，就成了时刻要考虑的东西。
- 面向服务架构(Service-Oreinted Architecture) 是将软件设计成一组可互操作的服务的一套原则或方法论。通常在考虑系统架构时才会触及SOA。
- 基于组件开发(Component-Based Development) 是一种软件工程实践，设计时通常要求组件之间高内聚，松耦合。其接口可能是OO的，调用方式可能是以Service的方式。基于组件开发关注系统层次、子系统边界和子系统间通讯的的设计，处于代码层面但不像OOP的一样是时刻需要运用的东西。
面向XX就是为了解决系统成长过程中遇到问题，而采用的一些范式。
举例来说：你开始给一个企业做MIS系统。
当这个企业来很小的时候，用简单的面向对象编程，数据库+服务端+浏览器已经满足需求。不需要考虑面向组件开发和SOA.
慢慢的，这个企业长大了，当初简单的mis系统，变得越来越复杂和庞大。系统中有很多重复功能的代码。当这些功能模块的业务有变化时是你头疼的时候：代码中有很多地方要修改，遇到新员工，有时总是改不全。系统上线问题越来越多，需求响应时间也越来越长。经常被客户骂：他X的，这么简单的需求搞了半个月都上不了线。去年xxxxxxx两天就上线了。
此时，你会考虑怎么把系统中那些重复的代码统一起来。你会考虑到组件化，即“面向组件”。你把一个个比较独立的业务模块约定好接口，开发成组件。以后再有类似的功能模块，直接调用这个组件，即节省开发成本，又容易维护。
后来，企业变成了集团公司。已经上线了很多套各种各样的mis系统。虽然大部分系统都实现了组件化。但做为一个集团公司，仍然有很多共同的业务，不同mis系统中有很多功能重复的模块。此时又面临业务升级困难，难以使用的问题：一个需求可能要涉及很多套mis系统的升级。同时每套系统都有独自的界面，客户录入一个数据，要打开N个页面，要登陆N次，叫苦不迭。各种数据不一致的问题接踵而来。
SOA来啦。架构师把各个系统功能类似的模块抽象成服务，重复的模块再也没有了，不同系统间互相调用服务接口。以前要自己写一大堆代码，现在搞清楚接口，直接调用另一套Mis系统的服务接口就 OK了。也有了单点登陆，有了portal，有了搜索服务，有了知识库等等。
但是问题又来了：
总有一些很重要的服务，所有的系统都会依赖它，它出一点问题，所有系统都停转。你开始考虑双机，热备，负载均衡。
以前用的IBM的主机+Oracle数据库+EMC的存储，再后来买更贵的性能更好的。慢慢的你发现，企业挣的钱都他妈的给了IOE。你开始考虑分布式，开始考虑使用开源产品。
举例来说：你开始给一个企业做MIS系统。
当这个企业来很小的时候，用简单的面向对象编程，数据库+服务端+浏览器已经满足需求。不需要考虑面向组件开发和SOA.
慢慢的，这个企业长大了，当初简单的mis系统，变得越来越复杂和庞大。系统中有很多重复功能的代码。当这些功能模块的业务有变化时是你头疼的时候：代码中有很多地方要修改，遇到新员工，有时总是改不全。系统上线问题越来越多，需求响应时间也越来越长。经常被客户骂：他X的，这么简单的需求搞了半个月都上不了线。去年xxxxxxx两天就上线了。
此时，你会考虑怎么把系统中那些重复的代码统一起来。你会考虑到组件化，即“面向组件”。你把一个个比较独立的业务模块约定好接口，开发成组件。以后再有类似的功能模块，直接调用这个组件，即节省开发成本，又容易维护。
后来，企业变成了集团公司。已经上线了很多套各种各样的mis系统。虽然大部分系统都实现了组件化。但做为一个集团公司，仍然有很多共同的业务，不同mis系统中有很多功能重复的模块。此时又面临业务升级困难，难以使用的问题：一个需求可能要涉及很多套mis系统的升级。同时每套系统都有独自的界面，客户录入一个数据，要打开N个页面，要登陆N次，叫苦不迭。各种数据不一致的问题接踵而来。
SOA来啦。架构师把各个系统功能类似的模块抽象成服务，重复的模块再也没有了，不同系统间互相调用服务接口。以前要自己写一大堆代码，现在搞清楚接口，直接调用另一套Mis系统的服务接口就 OK了。也有了单点登陆，有了portal，有了搜索服务，有了知识库等等。
但是问题又来了：
总有一些很重要的服务，所有的系统都会依赖它，它出一点问题，所有系统都停转。你开始考虑双机，热备，负载均衡。
以前用的IBM的主机+Oracle数据库+EMC的存储，再后来买更贵的性能更好的。慢慢的你发现，企业挣的钱都他妈的给了IOE。你开始考虑分布式，开始考虑使用开源产品。