With AOP, Component Oriented == Object Oriented

在本人之前的《Component/Service Oriented Software System Development Thinking 》一文中，我将包括BinaryLevel和Source Code Level的软件模块统称为Component。这种分类方式，和传统的对Component的一般定义应该说并不是十分一致。本文就是要对我为什么要这样分类作一些补充解释。

 

-

 

传统的定义中，一般认为，Component Oriented和Object Oriented有本质区别，在O'Reilly的《Programming .Net Component》一书中，列举了两者的主要区别和Component Oriented的基本原设计准则。没看过的读者可以下载下来看看，这里给的链接只包含该书了第一章，当然，这里说的区别和设计准则是包含在这一章里的。

 

区别：

1. Building Blocks Versus Monolithic Applications - 多程序集还是单一程序集

2. Interfaces Versus Inheritance - 黑盒还是白盒

 

设计准则：

1. Separation of cnterface and implementation

2. Binary compatibility

3. Language idependency

4. Location transparency

5. Concurrency management

6. Version Control

7. Component-based security

 

-

 

那么，我为何将这两个原本有区别，区别似乎还不是很小的概念归在一个统一的概念-“Component”中呢？

 

首先我们来谈谈，上面提到的两个主要区别。

 

原书的作者的主要观点是，组件总应该是语言无关的二进制级别的黑盒模型，而OO则一般是语言相关的源代码级别的白盒模型。接着又说到，组件的重用，一般是不去关心其内部细节，而以大颗粒的功能调用或类继承来使用；而OO则可以以细颗粒去继承，并且可以方便的通过设计模式的运用组合、拦截函数调用，插入代码、修改内部细节等等，类的继承，也可以是细颗粒的。因此，说两者有本质区别。

 

从作者考虑这个问题的角度，也是传统的组件定义的角度来说，以上的论点当然是不错的。但是，有一项思想或者说技术的出现，很大程度上打破了以上的界限，是什么技术呢？您可能已经词到嘴边了，没错——AOP。

 

-

 

关于AOP的基础思想介绍，我这里就不多说了，如果您还不是很了解，可以在博客园站内搜索一下AOP。我这里要为您说明的是，为什么有了AOP的思想，以上这种CO和OO的界限和区别就大大减弱了呢？

 

当然这里我要特别提一下，我这里指的AOP，主要指有二进制级别织入能力的AOP，如Teddy所写的一个.Net下的AOP工具AspectWeaver，而不仅仅是像Castle.Aspect#这样的基于DynamicProxy的AOP实现。

 

因为AOP的二进制级别的织入能力，更直白一点说，是AOP使得操作二进制级别的组件或者说程序集就和操作源代码级别的模块一样容易的能力，使得只要您愿意，就可以像有源代码的组件一样使用二进制的程序集。在二进制级别将一个程序集分解成多个程序集，或者多个程序集者病程一个程序集同样是轻而易举的。所谓黑盒还是白盒的区别，也就变得没有太大的意义了。现在都可以看作白盒。只要相应的源代码能够编译成相互兼容和可识别的二进制程序集，那么我们就能在二进制级别对程序模块进行任意的重用和改造。

 

当然，上面所列的组件化设计的基本原则，现在还是适用的。同时，这种二进制级别的细节操纵能力，使得AOP不但能够使用OO中所有可以使用的工具和设计思想，还是一个超集，可以做到许多超越OO限制的功能，如Mixin，接口实现，基类变更，静态代码拦截等等/插入/删除等等，感兴趣的朋友可以自查看相应的资料。

 

-

 

正是因为AOP的这种特殊能力，很大程度上破除了二进制组件和OO组件的界限，更将带来软件开发思想，可重用软件设计等的巨大变革，和很多以前实现不了的可能性变为现实。这样的变革的大致风貌我在之前的文章《重新诠释AOP》中已有些许描述，在稍后的《Looking into Component》中，我也将会有进一步阐述。敬请期待！