《模式 工程化實現及擴展 (設計模式 C#版)》 - 書摘精要

(P3)

面向對象的典型原則能夠劃分爲兩類 —— 「面向類」的和「面向包」的；

「面向類」的，包括：
SRP —— 單一職責原則；
OCP —— 開放封閉原則；
LSP —— 里氏替換原則；
DIP —— 依賴倒置原則；
ISP —— 接口隔離原則；

「面向包」的，包括：
REP —— 重用發佈等價原則；
CCP —— 共同封裝原則；
CRP —— 共同重用原則；
ADP —— 無環依賴原則；
SDP —— 穩定依賴原則；
SAP —— 穩定抽象原則；

「面向包」的6個原則能夠再劃分爲兩類：REP、CCP、CRP 強調的是包的內聚性設計要求，而 ADP、SDP、SAP針對的是包間耦合性要求；

(P7)

里氏替換原則是站在模式對象這一方，依賴倒置原則是站在客戶程序這一方。模式對象這一方將「相對多變的」子類視同它的接口(或父類)，而客戶程序依賴的內容不是「相對多變」的子類，而是「相對穩定」的接口；

(P10)

迪米特法則不但願與非「友」的類型創建直接聯繫，即使聯繫的都是「友」也要和「最近的密友」聯繫，而且聯繫的時候最好不要談「隱私」(即專門類型)，要用一些相對廣爲人知的知識進行交互；

迪米特法則在生活中最直觀的表現就是「人脈」，不過不一樣點在於迪米特法則但願的是人脈窄，而現實中咱們但願的是人脈寬、路子廣；

(P15)

開發軟件的主要目的是知足用戶的須要，同時得到收益；

工程化軟件的特色不只僅是看上去很「面向對象」，關鍵是可以用簡潔、必要的面向對象手段解決問題，少投入、多產出；

(P18)

好的命名空間規劃是工程化代碼與非工程化代碼一個最直觀的區別；

(P21)

在.Net中委託也是一個抽象手段，它是對方法的抽象；

(P22)

委託是對具體方法的抽象，它屏蔽了委託的調用者與實際執行方法間的關聯關係；

(P25)

方法，就是一小段能夠重用的處理過程；

事件是委託的特例，「特」表如今以下4個方面：
—— 返回值爲 void；
—— 第一個參數 sender 是 System.Object；
—— 第二個參數繼承自 EventArgs 或其子類；
—— 僅限兩個參數；

(P29)

C# 爲咱們提供了5種抽象能力：
Class —— 對現實世界的抽象；
Interface —— 對 Class 行爲的抽象；
Delegate —— 對方法的抽象；
Attribute —— 對類型元數據的抽象；
Generics —— 給上述因素進一步、進兩步、直至進N步抽象的機會；

(P33)

接口和參數更明確，並且不只僅停留在 UML 的圖紙上，在編碼和調用過程當中都起到剛性的檢查做用；

(P34)

若是代碼將被反覆重用，只要進度容許，儘可能泛型；

(P49)

不建議在 .Net 2.0 版本之前的項目中採用接口注入的方式；

(P76)

工廠方法模式是 GOF 23個設計模式中最具啓發效果的，它告訴咱們能夠經過增長新的對象專門管理「變化」；

(P78)

靜態類不能被繼承，因此看起來靜態類更像之前的 API 集合，有點不那麼「面向對象」的味道；

(P93)

單件模式要作的就是經過控制類型實例的建立過程，確保客戶程序使用的都是建立好的同一個實例；

(P105)

Singleton 模式在 .Net 平臺一個最簡潔但又相對線程安全的實現方式：

sealed class Singleton
{
    Singleton() {}
    public static readonly Singleton Instance = new Singleton();
}

(P115)

使用時能夠把工廠方法、靜態工廠、簡單工廠和抽象工廠混合起來：

靜態工廠能夠做爲最底層的一個「泵」，它提供最原始但最粗顆粒度對象的建立，甚至僅僅返回弱類型的 object 也能夠，後綁定調用(或被稱爲晚綁定)能夠經過一個集中的靜態工廠完成。之因此把它放在最下面，主要是由於它不能被繼承和進一步擴展，因此讓它作最基本但又最通用的工做。實際項目中能夠用 Activator 類充當這個角色；

簡單工廠的適用範圍很廣，根據應用的須要在某些須要隔絕抽象與具體的位置上使用；

工廠方法應用在具備一套較縱深層次的對象上，能夠經過具體工廠類型選擇繼承層次上一個合適的具體產品來構造，而客戶程序則把握住抽象的工廠類型和抽象的產品類型便可；

抽象工廠方法則用在某些特定領域上，面向某些應用子系統或專業領域的對象建立工做，相對而言，咱們能夠把它更多地用於項目的中、高層設計中；

(P142)

項目中，使用原型模式的關鍵不在於定義一個 IPrototype 接口，而在於如何又好又快地完成克隆過程；

(P148)

適配器主要有3個做用：
—— 完成舊接口到新接口的轉換；
—— 將「既有系統」進行封裝，邏輯上客戶程序應該不知道「既有系統」的存在，將變化隔離在適配器部分；
—— 若是客戶程序須要遷移，僅須要在適配器部分作修改；

適配器模式配合代理模式，它們能起到「穩定性邊界」的做用，即當一個範圍內的對象相對穩定，而與之交互範圍內的對象相對不穩定(或不肯定可否穩定)時，咱們能夠考慮在邊界上增長適配器和代理；

(P166)

橋模式解決的是對抽象中正交變化因素的進一步分解及銜接；

(P206)

在實際項目中，裝飾模式的應用比例不高，主要是由於追蹤和調試相對困難，多數狀況下項目中更願意採用多接口組合的方式；

(P216)

值類型要麼是堆棧分配的，要麼是在結構中之內聯方式分配的，值類型包括簡單類型、枚舉類型和結構類型；

引用類型是堆分配的，操做它們的時候咱們是基於引用完成的，引用類型包括類類型、接口類型、委託類型和數組類型；

(P224)

外觀模式是屏蔽複雜性的，不少時候代理模式的控制自己也就是對各類複雜性的屏蔽，只不過外觀處理的是一個邏輯上的「子系統」，並且其封裝後的結果並無具體抽象接口的要求，但在代理模式中客戶程序須要的接口事先是明確的。外觀模式每每會生成一個更易於使用的新接口，而代理模式保持接口一致；

(P226)

代理模式既以設計模式出現，用時也是很重要的架構模式；

(P237)

CoR 模式普遍應用於架構模式、大型項目的基礎平臺及 SOA 環境下的企業服務總線(Enterprise Service Bus, ESB)，其交互過程當中每每涉及分佈式事務性鏈式操做，消息隊列、數據庫、外部服務及雲計算環境均可以針對一個 Request 內容用「鏈式」方法鏈接；

(P242)

模板方法模式的概念雖然簡單，但它卻充斥在軟件架構的方方面面；

(P245)

模板方法模式主要採用繼承(或接口實現)完成，而策略模式更多經過委託解決；

模板方法模式關注點在於算法中的每一個步驟的差別及可替換性，而策略模式則是對整個算法進行替換；

(P273)

從工程角度看，命令模式最大的優點在於它爲應用的擴展性、高可用性提供了基礎；

(P284)

「依賴於抽象」 —— 若是客戶程序使用一個繼承體系上的某個具體類型的時候，就從這個體系上抽象出一個接口，而後經過建立型模式讓客戶程序按照接口要求向客戶程序提供實例；

(P295)

備忘錄模式是爲了給應用一個 Undo() 的機會；

(P317)

ABC (Address、Binding、Contract) 組合常被稱爲 (ServiceEndpoint)；

(P333)

命令模式解決的是「作什麼」，它把到底須要作什麼的問題延遲到子類中定義；

策略模式關注於「怎麼作」，也就是爲了完成一個既定的處理，算法上怎麼實現的問題；

(P351)

若是對象的不肯定性來自於構造過程，那麼藉助「建立型模式」，控制目標對象的數量或者把建立工做交給一個獨立的對象完成。這樣，業務對象自身不會爲了構造其餘對象產生直接依賴。固然，實現該目標有一個前提，那就是待構造的對象先被抽象；

若是對象的不肯定性來自結構，則能夠考慮「結構型模式」，用一個相對抽象的對象協調結構上的依賴關係；

若是不肯定性來自執行過程，則能夠考慮「行爲型模式」，行爲型模式多數時候是對執行邏輯複雜性的進一步分解，好比某些操做、交互過程過於複雜，這時就須要對它們分解。行爲型的思惟方法就是把這些複雜並且易變操做和交互對象化，同時抽象它們的行爲，確保這些對象後續能夠被替換；

(P381)

視野決定高度；