面向对象、面向组件、面向服务,以及面向xxx.docxVIP

无论什么系统变大了之后，就会有一系列问题。面向 XX 就是为了解决系统成长过程中 遇到问题，而采用的一些范式。 举例来说：你开始给一个企业做 MIS 系统。当这个企业来很小的时候，用简单的面向 对象编程，数据库 +服务端 +浏览器已经满足需求。不需要考虑面向组件开发和 SOA。 慢慢的，这个企业长大了，当初简单的 mis 系统，变得越来越复杂和庞大。系统中有很 多重复功能的代码。 当这些功能模块的业务有变化时是你头疼的时候： 代码中有很多地方要 修改，遇到新员工，有时总是改不全。系统上线问题越来越多，需求响应时间也越来越长。 经常被客户骂：他 X 的，这么简单的需求搞了半个月都上不了线。去年 xxxxxxx 两天就上线 了。此时，你会考虑怎么把系统中那些重复的代码统一起来。你会考虑到组件化，即“面向 组件”。你把一个个比较独立的业务模块约定好接口，开发成组件。以后再有类似的功能模 块，直接调用这个组件，即节省开发成本，又容易维护。 后来，企业变成了集团公司。 已经上线了很多套各种各样的 mis 系统。虽然大部分系统 都实现了组件化。 但做为一个集团公司， 仍然有很多共同的业务， 不同 mis 系统中有很多功 能重复的模块。此时又面临业务升级困难，难以使用的问题：一个需求可能要涉及很多套 mis 系统的升级。同时每套系统都有独自的界面，客户录入一个数据，要打开 N 个页面，要 登陆 N 次，叫苦不迭。各种数据不一致的问题接踵而来。 SOA 来啦。架构师把各个系统功 能类似的模块抽象成服务， 重复的模块再也没有了， 不同系统间互相调用服务接口。 以前要自己写一大堆代码，现在搞清楚接口， 直接调用另一套 Mis系统的服务接口就 0K了。也有 了单点登陆，有了 portal ，有了搜索服务，有了知识库等等。 但是问题又来了：总有一些很重要的服务，所有的系统都会依赖它，它出一点问题，所 有系统都停转。你开始考虑双机，热备，负载均衡。以前用的IBM的主机+Oracle数据库+EMC 的存储，再后来买更贵的性能更好的。慢慢的你发现，企业挣的钱都他妈的给了 10巳你开 始考虑分布式，开始考虑使用开源产品。 。。 补充 面向对象技术的基础是封装－－接口与实现分离， 面向对象的核心是多态－－这是接口 和实现分离的更高级升华，使得在运行时可以动态根据条件来选择隐藏在接口后面的实现， 面向对象的表现形式是类和继承。 面向对象的主要目标是使系统对象化， 良好的对象化的结 果，就是系统的各部分更加清晰化，耦合度大大降低。 面向组件技术建立在对象技术之上， 它是对象技术的进一步发展， 类这个概念仍然是组 件技术中一个基础的概念， 但是组件技术更核心的概念是接口。 组件技术的主要目标是复用 ――粗粒度的复用，这不是类的复用，而是组件的复用，如一个 dll、一个中间件，甚至一 个框架。一个组件可以有一个类或多个类及其它元素（枚举、 ）组成，但是组件有个很明显 的特征，就是它是一个独立的物理单元，经常以非源码的形式（如二进制， IL）存在。一个 完整的组件中一般有一个主类， 而其它的类和元素都是为了支持该主类的功能实现而存在的。 为了支持这种物理独立性和粗粒度的复用， 组件需要更高级的概念支撑， 其中最基本的就是 属性和事件，在对象的技术中曾一度困扰我们的类之间的相互依赖问题 /消息传递问题，迄 今为止我所知道最好的解决方案就是事件。 要理解组件思想， 首先要理解事件的思想和机制。 我一直坚持以为，一个组件的外形 /外貌应该是简单的、应该是清晰的、没有冗余的东 西、也没有无关紧要的东西， 这个外貌通过接口来描述， 接口中可以发布事件、 属性和方法。 这三种元素就足以描述一个组件外貌的所有特征。 比如，我曾经用封装的一个完成端口组件， 其外貌接口中只有四个方法， 三个事件， 三个属性而已， 而该组件的内部实现却有几千行代 码。所以在设计一个组件的时候，需要做很多的权衡，哪些需要通过接口暴露出来，哪些应 当作为私有实现。有时， 你会处于两难的境地，因为让组件更容易使用，所以需要给出很多 默认的参数， 但为了使该组件更通用， 你又需要暴露更多的属性可以让人设定、 暴露更多的 方法和事件满足更复杂的功能。 你需要抉择， 你需要权衡。难怪有人会说， 软件的设计更像 是艺术，因为艺术的美在于恰当的抉择和平衡。我的经验是， 在保持低耦合度的前提下，组 件的接口足以对付当前的应用就好。 如果日后需要加强功能， 那就重构然后增强它， 这是很 容易的，因为早就说了嘛，保持组件的低耦合度。 需要说明一下的是，我们通常所说的控件(如按钮)也是一种组件，可以这么认为，控 件是一种具有 UI 形式的组件。插件( Addin/Plugin )也是一种特殊的组件，插件的单独存在 是没