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