By 高焕堂 2012/05/28
框架API：制约力量的强弱等级
1. 从API可看出强弱地位
API的本意是：AP(应用程序)与系统平台之间的接口，也就是一种互动的协议。后来，逐渐扩大为较为广泛的意义：泛指软件组件之间的接口，也就是两方软件组件开发者之间的互动协议。这让API与UI有了明确的区别：
- UI(User Interface)是指软件(如AP)与用户(User)之间的接口，也就是双方互动的协议。
- API是指软件(如AP)与软件(如框架)之间的接口，也就是双方开发者所订定的软件组件互动协议。
大家都知道，接口(Interface)是双方接触的地方，也是双方势力或地盘的界线。谁拥用接口的制定权，谁就掌握控制点，就能获得较大的主动权(或称为主导权)，而位居强龙地位；而另一方则处于被动地位，成为弱势的一方，扮演地头蛇角色。
随着框架API这项礼物的大量赠送而广为流传时，其所携带的制约力量就逐渐扩展出去，于是势力和版图就日益扩大了。君不见，Microsoft的.NET框架，以及Google的Android框架都是当礼物送人，而让Microsoft和Google的势力无限延伸，进而主宰了整个产业局势。例如Android的API接口：
图1、 Android框架基类与子类的接口
从这接口可看出它的不平等性质：
- onCreate()函数名称定义于框架基类Activity里。
- onCreate()函数的程序代码是写在myActivity子类里；由子类提供给基类来呼叫或调用。
从这个「不平等」性质，就知道Activity基类拥有主动权，是强势的一方；而myActivity子类则是弱势的，受制于对方。于是，可以推论出来：Activity基类的开发者(即拥有者)处于强龙地位，而myActivity子类的开发者(即拥有者)处于地头蛇角色。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
例如，Android平台设计的特色是：1)强龙的软件(即Android本身)掌握了控制点；2)强龙软件呼叫地头蛇的软件。为了实现强龙软件真正掌握控制点，就必须由强龙软件来呼叫地头蛇软件，而且其呼叫接口，应该由强龙软件开发团队所定义的。为了定义这项接口，就得写个框架基类去与地头蛇软件相互搭配。于是，Android提供了Java层的应用框架和底层的HAL(Hardware Abstraction Layer)驱动框架。如下图：
图2、 Android的Java层应用框架与HAL驱动框架(一)
这是从「基类与子类继承关系」的观点来看的，基类属于框架；而子类则属于AP。于是，上图就相当于：
图3、Android的Java层应用框架与HAL驱动框架(二)
无论是Java层应用框架或是HAL驱动框架都是由商业强龙(即GoogleHAL框架公司)出资开发的。然后，强龙必须将HAL框架原始程序代码提供给驱动开发者(地头蛇)，地头蛇就把HAL框架和他的驱动程序一起编译和连结起来。同理，强龙必须将Java层应用框架原始程序代码提供给应用程序开发者(地头蛇)，地头蛇就把Java框架和他的应用程序一起编译和连结起来。此时，HAL框架和Java框架会提供主动型API来呼叫地头蛇的程序。有了上述的强龙系统架构来支撑强龙商业架构，让Google稳居商业(或产业)分工合作上的强龙地位。
2. 制约力量的强弱等级
框架API让基类拥主导(Dominate)地位，也就是说，基类主导了子类。例如，下图1-6里的onCreate()函数所构成的API，其制约力量强弱程度比率为：
基类:子类 ==> 0.8 : 0.2
就此API而言，基类具有高度的制约力量可主导子类。其理由是：1)基类开发者制定了接口(例如决定onCreate()函数名称及其参数型态)；2)基类呼叫AP子类的onCreate()，使得这框架基类的制约力量有0.8(比率是0.8:0.2)。如下图：
图4、 基类与子类接口的制约力量
请看看下图1-5，其中的AP子类呼叫基类的setContentView()具象函数，子类拥有较大控制权。也就是说，相对上，框架基类与应用子类之间的制约力量比率是(0.4:0.6)。其理由是：1)基类开发者制定了接口(例如决定setContentView()函数名称及其参数型态)，应用子类并没有决定权；2)子类呼叫基类的setContentView()，使得这框架基类的制约力量只有0.4(比率是0.4 : 0.6)。如下图：
图5、制约力量的等级
然而，值得特别留意的情形是，子类是否主动呼叫基类的函数。如果像上图一样，基类Activity透过先呼叫子类myActivity的onCreate()函数，此时子类才呼叫Activity的setContentView()函数。由于子类是被动呼叫基类(并非主动呼叫)，就不产生子类对基类的制约力量，所以不必把图中的(0.4 : 0.6)制约力量考虑进去。因之，从整体上而言，上图里的框架基类仍拥有高达(0.8 : 0.2)的主导性。刚才说过了，框架API通常具有两项特性：
1) 基类开发者制定(Define)了接口(即函数名称及其参数型态)。
2) 子类实作(Implement)此接口，并由基类呼叫(Call)其函数。
此时让框架基类获得高达(0.8:0.2)的主导性。许多人常问到：甚么情况下，框架基类才能获得(1.0:0.0)的绝对主导性呢? 答案是：还需要具备另一个条件：由框架来诞生应用子类的对象。如下图：
图6、绝对强势的制约力量
此时，框架基类具有绝对的主导性，其制约力量强弱程度比率为：
基类:子类 ==> 1.0 : 0.0
也就是具有极强大的制约力量。值得留意的是，不一定是由自己亲属的基类(如Activity或Activity的父类)来诞生子类(如myActivity)物件。常常是由框架里的其它基类来诞生。例如，Android框架的基类与应用子类之间，就实现了上述(1.0:0.0)的强大制约力量，让Android框架(内含基类)拥有制高点(即主控权)。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
3. Why，框架API?
很多人常提出疑问：提供API的途径何其多? 为何特别强调「框架」的API呢? 例如，一般链接库(Library)也提供API给开发者使用、网络服务(Web Service)也是一种API，为何只谈框架API呢? 为了回答这问题，必须回顾过去20年来的软件开发经验了。其中有两项重要的事迹：
- 1980年代后期，CORBA是一项对象导向的服务标准API，实现此项标准的系统中，最著名的商业中间键软件就是Orbix系统。然而，在系统架构上，API是一种制约力量，不是一种礼物，不能用来嘉惠予AP开发者。导致CORBA和Orbix系统架构无法支撑理想的商业模式，而终告消失匿迹。
- 1990年代中后期，继CORBA之后的是Microsoft公司推出COM/DCOM系统架构，虽然提供了当时先进的对象导向(Object-Oriented)的API，但还是API，仍然是一种制约力量，不是一种礼物，不能用来嘉惠予AP开发者。与CORBA和Orbix一样的系统架构，一样无法支撑理想的商业模式，也终告消失匿迹。
后来，IT业界逐渐发现：API可用来框住应用程序(AP)，如同一把利剑；若要获得开发者的青睐，利剑必须搭配面包，就像钓鱼钩必须搭配鱼饵，才能吸引鱼群。于是，Microsoft改变观点，把焦点放在面包上，发现对象导向技术里的抽象类别(Abstract Class)及其提供的预设函数(Default Function)以及其它具体类别，所整合而成的框架(Framework)正式一项极具诱惑力的鱼饵。此外，由框架所提供的主动型 API，也能发挥巨大的控制力。因之，Microsoft于2001推出.NET框架来取代COM/DCOM，由于.NET框架融合了面包与利剑，既能嘉惠广大的开发者，又能有效框住众多的应用程序。.NET框架是Microsoft赠送给广大的开发者的最佳礼物，表达了Microsoft对全球广大第三方开发者关怀和爱心，让他们因.NET而受惠。
到了2007年，Google也依样画葫芦，买来Android框架，当成礼物赠送给全球的手机硬件厂商，也赠送给全球广大的AP开发者。由于Android框架「礼物」嘉惠予硬件厂商，所以全球的硬件厂商也是受惠者，因而大力支持Android，也让Android声势扶摇直上。Android框架是面包与利剑的融合体，不仅嘉惠予硬件厂商，也嘉惠予全球数以万计的广大AP开发者，同时也主导了这些开发者。
由于Google热情投入开发框架API，并当成礼物来送人，除了嘉惠众多硬件厂商，也嘉惠了全球的AP开发者，让人人能拥有「没钱就改版，改版就有钱」的利益。古贤者老子说：「圣人无积，既以为人己愈有，既以予人己愈多。」从历史可知，秦始皇、汉武帝热情投入万里长城的兴建，而成为最大获利者。如今，Google和微软都热情投入软件框架的开发，而成为幸运的最大赢家。◆
[Go Back]
