atitit. api 設計 原則
---歸一化
1.1.
叫做歸一化
1
1.2.歸一化
的例項：一切物件都可以序列化/tostring
通過介面實現
11.3.
泛檔案概念、
21.4.
遊戲行業的一切皆精靈
2介面繼承實質上是要求「做出乙個良好的抽象，這個抽象規定了乙個相容介面，使得外部呼叫者無需關心具體細節，可一視同仁的處理實現了特定介面的所有物件」——這在程式設計上，叫做歸一化。
歸一化使得外部使用者可以不加區分的處理所有介面相容的物件集合——就好象linux的泛檔案概念一樣，所有東西都可以當檔案處理，不必關心它是記憶體、磁碟、網路還是螢幕（當然，如果你需要，當然也可以區分出「字元裝置」和「塊裝置」，然後做出針對性的設計：細緻到什麼程度，視需求而定）。
a、一切物件都可以序列化/tostring
b、一切ui物件都是個window，都可以響應視窗事件。
——必須注意，是一切（符合xx條件的）物件皆可以做什麼，而不是「一切皆物件」。後者毫無意義。
軟體設計同樣。比如說，訊息迴圈在派發訊息時，只需知道所有ui物件都是個window，都可以響應視窗訊息就足夠了；它沒必要知道每個ui物件究竟是什麼——該物件自己知道收到訊息該怎麼做。
合理劃分功能層級、適時砍掉不必要的繁雜資訊，一層層向上提供簡潔卻又完備的資訊/介面，高層模組才不會被累死——kiss是最難也是最優的軟體設計方法，沒有之一。
總結：物件導向的好處實際就這麼兩點。
一是通過封裝明確定義了何謂介面、何謂介面內部實現、何謂介面的外部呼叫者，使得大家各司其職，不得越界；
二是通過繼承+多型這種內建機制，在語言的層面支援歸一化的設計，並使得內行可以從**本身看到這個設計——但，注意僅僅只是支援歸一化的設計。不懂如何做出這種設計的外行仍然不可能從瞎胡鬧的設計中得到任何好處。
顯然，不用物件導向語言、不用class，一樣可以做歸一化的設計（如老掉牙的泛檔案概念、遊戲行業的一切皆精靈），一樣可以封裝（通過定義模組和介面），只是用物件導向語言可以直接用語言元素顯式宣告這些而已；
而用了物件導向語言，滿篇都是class，並不等於就有了歸一化的設計。甚至，因為被這些花哨的東西迷惑，反而更加不知道什麼才是設計。
事實上，unix系統提出泛檔案概念時，物件導向語言根本就不存在；遊戲界的精靈這個基礎抽象，最初是用c甚至彙編寫的；……。
作者::
綽號:老哇的爪子
（全名：：
attilax
akbar al rapanui 阿提拉克斯 阿克巴 阿爾 拉帕努伊 ）
漢字名：
艾提拉（
艾龍），
email:[email protected]
atiend
設計模式（一） 設計原則
此系列只是對 大話設計模式 的鞏固總結。在理解設計模式之前，需要理解幾個 物件導向的設計原則 單一職責 乙個類只專注於做一件事。黎克特制替換 基類存在的地方，子類可以將其替換。依賴倒置 實現盡量依賴抽象，不依賴具體實現。介面隔離 為使用者提供盡可能小的的單獨介面，而不是大而全。迪公尺特法則 乙個實體...
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
設計原則 單一職責原則
1 原則的定義 2 原則設計的初衷 3 能解決哪些問題 4 有哪些場景可以使用 單一職責原則，英文名single responsibility principle,縮寫為srp。乙個類或者模組只負責完成乙個職責 或者功能 也就是說，不要設計大而全的類，要設計粒度小，功能單一的類。換個角度來講就是，乙...