Android是一个应用框架,而不是类别库

Android是一个应用框架,而不是类别库

有人拿「未插完的花盆」來比喻框架，似乎更傳神﹗插花老師先插上背景花，並留下空間，任學生發揮，繼續插完成。框架設計師提供了基本類別，也預留空間讓您發揮，繼續衍生出子類別。

	應用框架	類別庫
目的	讓應用程式師衍生出具體類別，衍生時可修正類別，才誕生物件。	讓程式師拿現成類別來誕生物件，類別並未預留空間給程式師來修正。
	應用框架中的類別的函數，常呼叫應用程式中的函數。	應用程式的函數只能呼叫類別庫中的函數，反之不可。
	含有類別間之關係，其預設了物件間的互助合作關係。	類別是獨立的，並未設定物件間的溝通方式。
	物件常含預設計行為(DefaultBehavior) ，預設行為可讓應用程式師修正之。	物件的行為皆是固定的，無法修正之。

关于这点,类似于MFC的消息机制,
比如在WM手机上有重力感应器,如果屏幕方向发生改变了,MFC的框架会以WM_SIZE或者WM_SETTINGCHANGE消息事件通知所有驻内存的程序窗口做出处理,程序应用可以截获WM_SIZE或者WM_SETTINGCHANGE消息做出自己的处理,也可以让MFC框架调用default window proc做出预设的处理.

和传统的App不一样的是:
传统的App是应用程式去调用类别库,进而类别库调用系统而完成整个用户请求,系统一直是被动的;
而框架结构里主动权在系统,系统或许会以广播的形式发出事件消息,程式接受到消息做出自己的处理,这实际上达到了一种框架调用应用程式的效果.


您寫傳統程式時，主控權掌握在程式手中，其決定如何呼叫庫存函數﹔就像棒球比賽的「投手」一樣。反之，使用框架時，您的程式則擔任「捕手」之角色.

在Linux / Windows 的事件驅動觀念中，OS 會不斷與應用程式溝通，不斷修正其慣例，裨對外界的事件提供迅速反應與服務。


當客人問道﹕今天打幾折﹖這是個小問題，店員按慣例（即按公司規定）來回答﹕8 折。當客人討價還價而問道﹕可否打7 折﹖店員請教經理，但經理並未給予特別指示，店員就依照慣例回答﹕滿1000 元打7 折。

假如，經理有所特別指示，則店員修正慣例如上图

客人 == 用户;  店员 == OS;  经理 == 框架; 应用 == 总裁.

总裁把公司的新的销售政策告诉给经理人员;当客人来的时候,客人通过店员询问
东西的价格的时候,店员可以直接告诉客人(预设值);而当客人问是否能打折或打几折的时候,店员就需要请示经理了,如果经理暂时没答复,店员就可以按公司惯例给
优惠(预设值)



與店員的互動細節幾乎都由經理人員處理掉了，有必要才會打擾(呼叫)總裁，所以總裁就非常輕鬆了.这就是框架结构的好处!



来自本人阅读高焕堂先生的Blog后摘录的读书笔记更多内容请移步博客.