canonical

     分析學的離散形式是分而治之(Divide And Conquer)。 這一思想在軟件設計領域的重要性不言而喻。 大系統分解為小系統，小系統分解為模塊，模塊分解為對象，對象分解為函數，函數分解為增刪改查等動詞和集合/個體等名詞，如此遞歸下來。 在很多關于軟件的"最佳實踐"中，都列舉了這種分解過程中的注意事項，如高內聚，低耦合等。 但是為什么要強調這些概念，誰能保證這個checklist是完整的， 具體實踐過程中又當如何去做？ 我們能否跳出軟件的圈子，利用軟件領域之外的詞語重新表述一下這種思想？將大的系統分解為多個小的系統之后， 因為系統規模變小， 處理起來一般會容易一些， 但這是否就是分析學的全部？
     有一個小故事，說有人問一個科學家，如果地球文明將要毀滅，只有一句話可以傳給后人，那他最想告訴后代的是什么。那個科學家回答：宇宙萬物都是由原子組成 的。分析學的哲學基礎是還原論，原子論可以說是數千年來還原論最輝煌的勝利。原子論也清楚的向我們揭示了分析學的奧秘：千變萬化僅是事物的表象，分解之后 它們都由同質的基元構成。在分解的過程中，問題的規模越來越小，問題的數目似乎越來越多，但當問題空間因為某種原因"塌縮"的時候，分解后的子問題出現大 量的重疊，整個問題的復雜性出現了本質性的降低。FFT和動態規劃算法中所采用的也正是這種從異質到同質的解決方案。
      分解之后，我們希望得到的子系統是低耦合的，那么最好是完全不相關的，我們希望得到的子系統是高內聚的，那么最好是不可分的，在數學上，我們稱之為正交。 還原論最完美的載體是線性世界，而線性代數(或更廣義的群論)說了，線性系統完全由其正交的特征向量所構成的"核"(kernel）來刻畫，那大體上軟件 系統應利用少數可重用的模塊來構建。但線性代數又說了，特征向量的選擇方式是無窮多的，而且完全等價, 那大體上軟件系統的分解方式也是多種多樣的， 多數很難分出優劣。  線性代數還說， 特征向量個數僅由系統的維度（系統復雜性的一種度量）來決定， 那大體上軟件系統無論怎么分解， 總有一個復雜性的下限。過分簡單的架構僅能支持過分簡單的應用。線性代數沒有明說，但潛在的表達著，特征向量的地位是平等的，所以在高內聚，低耦合的基礎 上，軟件分解的原則中至少還要增加一條：對稱性, 以維護系統整體結構的平衡。
      很可惜，現實世界中發現了越來越多的非線性現象，以致于非線性研究本身已經成為了一門獨立的學科。不過，古老的教誨仍然有效，分解可以幫我們找回系統的線 性。在微積分所描繪的極限情形中，外力產生了加速度，然后加速度產生了速度，因與果就這樣實現了分離。（有人說，重整化方法在微觀世界的成功正是因為在極 度糾纏的臨界情況下微積分失效了，也許有些道理)。

      為了在軟件中實施分析學，我們需要一些技術手段。首先，需要一種命名機制，使我們能夠在思想中定義概念，并開始建模。所謂的對象，正是這樣一種機制。可以從以下的級列關系來理解這一點
1. 高級語言規定了數據的類型，使得我們可以為不同的內存塊指定不同的數據類型，從而在概念上對它們作出區分。
2. 當程序變得漸漸復雜起來，C語言提供的Struct結構體，使我們可以創建新的數據類型，可以將一組相關的數據放在一起，起個名字。而如果沒有 結構體，這種相關性就無法直接在程序中得到表達，必須紀錄在文檔中或者程序員的思想中。
3. 對象(Object)是比結構體(Struct)更加強大的命名機制，它可以將一組相關的數據和函數放在一起，起個名字。而且通過封裝和虛擬函數，一個對 象類型所表達的 不僅僅是它自身所代表的概念，它同時表達了它的派生類所具有的特征。即對象所表達的是一個概念的集合而不是一個單獨的概念。
4. 更復雜的程序中，對象之間的相互作用產生了某種確定的特征，出現了設計模式。
5. 這個級列的下一步是什么？

       對象化沒有什么神秘的地方，它只是使我們擁有了一種表述的工具。有時對象化比不對象化更遭，因為我們極有可能犯命名的錯誤。

     在沒有對象的概念的日子里，我們無法命名數據和函數的耦合，一些概念也就無法在軟件設計中得到自然的表達，因為它們在程序的世界中沒有名字！一旦我們能夠 命名系統中所有的概念，一扇門就被打開了，大量的可能性被發掘出來，形成了今天的面向對象技術。這其中最重要的就是軟件中的正交分解技術。首先是繼承。在 早期的C程序中，經常出現如下的代碼：
if a then
   a_work_1();
else if b then
   b_work_1();
end
…
if a then
   a_work_2();
else if b then
   b_work_2();
end

通過繼承，我們可以捕獲以上程序中的關聯性，代碼被改寫為如下方式
x = a or b;
x.work_1();
…
x.work_2();

但作為早期最主要的面向對象技術，很快繼承這個概念就不堪重負。通過繼承，系統中的所有關系被組織成了一個樹狀結構。隨著樹的層次越來越深，整個結構變得越來越不穩定，基類的小小變動隨時可能會造成雪崩似的影響。作為一個整體，對象也越來越難以被重用。

       此時，接口(Interface)應天命而生。從簡單的意義上來理解，接口可以被認為是對對象(Object)的正交分解。如果使用繼承，
class CHuman {
 public void eat(){..} // human eat
 public void sleep(){..} // human sleep
}
class CManager extends CHuman {
 public void fireEmployee() { ...} // manager fire employee
};
class CEmployee extends CHuman {…}
   公有繼承大致上對應于"is a" 關系， 即一種包含關系，在數學上稱為偏序(Partial Order)。
偏 序在邏輯上隱含的是一種推理，即我們可以根據基類的行為我們可以推論派生類的行為。所以當我們知道某人是經理（CManager)的時候, 我們可以推論出他是一個人，即他能吃能睡。很可惜，這種微妙的信息泄漏也許并不是我們所希望了解的，畢竟董事會雇傭一個職業經理人來為的是管理而不是吃 飯。
      應用組件技術，我們進行如下建模：
interface IHuman {
 bool eat();
 bool sleep();
};
interface IManager{
 bool fireEmployee();
};
class Manager implements IHuman, IManager{…};

Manager = IHuman + IManager

    接口打破了繼承所構建的僵化的樹狀結構，提倡靈活的網狀結構，使得整個系統結構扁平化，分解的粒度也更小。有了接口，是否就應該忘了繼承呢？不，推理關系仍然是重要的，只是不要濫用。

    最近幾年，面向方面編程(AOP)逐漸興起。從分解技術的角度上看，它代表了一個新的方向：形容詞與動詞的正交分解。例如，我們需要在一個事務中實現轉賬，
 實現轉賬這個功能可以很容易的編寫， "在一個事務中"這一修飾語被抽象出來稱為一個Aspect, 并單獨實現。通過AOP技術，我們將動作與所需要的修飾組合起來，完成所需要的功能。

      最后，談一談Reusablity這個概念.
軟 件設計是從需求領域到軟件技術實現領域的一系列模型映射，在每一個層面上都存在著多種正交分解方式。構建軟件的目的是為了滿足需求，所以整個映射過程應該 向著應用層傾斜。有一個說法叫做Object oriented to user, 我是從科泰世紀的陳榕那里聽來的。 我想這也正強調了從多種分解方式中作出選擇的準則。 可重用的對象意味著它更可能成為構建系統的"特征基元", 同時它的可用性隱含的表達了對應用層用戶的意義。 所以Reusability是一個比Objectlization和Encapsulation更為重要的一個概念。