(導(dǎo)讀 III)

?

作為面向?qū)ο蠡A(chǔ)設(shè)計(jì)原則的忠實(shí)體現(xiàn)，設(shè)計(jì)模式幫助我們?cè)趯W(xué)習(xí)過(guò)程中不斷強(qiáng)化以下五項(xiàng)原則性設(shè)計(jì)：

?

1. 單一職責(zé)原則 (SRP) —— 一個(gè)類應(yīng)該有且僅有一個(gè)引起變化的因素；

?

2. 開(kāi)放封閉原則 (OCP) —— 對(duì)擴(kuò)展開(kāi)放，對(duì)修改封閉；

?

3. Liskov 替換原則 (LSP) —— 子類可以替換為它的基類；

?

4. 依賴倒置原則 (DIP) —— 高層模型不應(yīng)該依賴于低層模塊，二者都應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細(xì)節(jié)。細(xì)節(jié)應(yīng)該依賴于抽象；

?

5. 接口隔離原則 (ISP) —— 一個(gè)類對(duì)另外一個(gè)類的依賴建立在最小的接口上；

?

(導(dǎo)讀 VII) 行為型模式關(guān)注與運(yùn)行過(guò)程中算法的提供和通信關(guān)系的梳理；

?

(P18)

如果代碼將被反復(fù)重用，只要進(jìn)度允許，盡量用泛型：

1. 省去 Cast 過(guò)來(lái) Cast 過(guò)去，提高了效率；

2. 抽象給代碼帶來(lái)更多適應(yīng)性；

3. 減少接口和參數(shù)的歧義；

?

(P80) 工廠方法地的意圖非常明確，它把類的實(shí)例化過(guò)程延遲到子類，將 new() 的工作交給工廠完成；

?

(P184)

適配器主要有三個(gè)作用：

1. 完成舊接口到新接口的轉(zhuǎn)換；

2. 將“既有系統(tǒng)”進(jìn)行封裝，邏輯上客戶程序不知道“既有系統(tǒng)”的存在，將變化隔離在 Adapter 部分；

3. 如果客戶程序需要遷移，僅需要在 Adapter 部分做修改；

?

(P187) 如果在一開(kāi)始學(xué)習(xí)的時(shí)候就有人提示一下多好；

?

(P260) “用面向?qū)ο笏枷朐O(shè)計(jì)的應(yīng)用常常會(huì)面臨對(duì)象實(shí)例過(guò)多的問(wèn)題。”

?

(P276) 外觀模式是屏蔽復(fù)雜性的，很多時(shí)候代理模式的控制本身也就是對(duì)各種復(fù)雜性的屏蔽，只不過(guò)外觀處理的是一個(gè)邏輯上的“子系統(tǒng)”，而且其封裝后的結(jié)果并沒(méi)有具體抽象接口的要求，但在代理模式中客戶程序需要的接口明確化了；

?

(P415) 同樣是排序算法，考慮到 CPU 和內(nèi)存容量的不同， 在手機(jī)和在PC計(jì)算機(jī)上可能采用不同的排序算法；

?

(P418)

排序算法選擇：

1. 實(shí)現(xiàn)簡(jiǎn)單 —— 冒泡排序策略；

2. 比較快速地對(duì)小數(shù)據(jù)量進(jìn)行處理 —— 快速排序策略；

3. 大數(shù)量 —— 外排序；

?

(P445) ORM —— Object —— Relation Mapping ；

?

(P457)

—— DataSet的優(yōu)勢(shì)：——

1. 使用 offline 的內(nèi)存數(shù)據(jù)庫(kù)；

2. 可以裝載多個(gè) DataTable;

3. 與 XML 的天然集成；

4. 有比較完善的內(nèi)存數(shù)據(jù)篩選、查詢機(jī)制；

5. 同時(shí)可以維護(hù)多個(gè)數(shù)據(jù)對(duì)象間的關(guān)聯(lián)關(guān)系；

6. 尤其對(duì)于兩層的數(shù)據(jù)應(yīng)用而言，提供了完善的數(shù)據(jù)使用周期支持；

?

—— DataSet的劣勢(shì) ——

1. 數(shù)據(jù)的業(yè)務(wù)語(yǔ)義不甚清晰，客戶程序必須了解字段的組成才能提取字段項(xiàng)；

2. 傳輸中有很多“冗余”的信息在傳遞；

3. 弱類型的數(shù)據(jù)結(jié)構(gòu)在開(kāi)發(fā)過(guò)程中不如強(qiáng)類型的數(shù)據(jù)實(shí)體使用方便；

4. 容量有限制；

5. 并非標(biāo)準(zhǔn)的數(shù)據(jù)結(jié)構(gòu)，在 WS-* 調(diào)用中考慮到互操作性要求，需要必要的轉(zhuǎn)換；

?

(P462) GOF 給我們最大的啟示就是把緊密引用在一起的對(duì)象通過(guò)抽象或增加第三個(gè)對(duì)象的辦法拆解得更加松散；

?

(P482) 模式的使用都是針對(duì)某些特定變化而引入的；

?

(P495)

MVC 模式設(shè)計(jì)是 M 相對(duì) V 穩(wěn)定的基礎(chǔ)上考慮的，但如果 M 本身相對(duì) V 變化更快， MVC 模式的應(yīng)用效果就會(huì)打折扣。它的主要優(yōu)勢(shì)在于同一 M 可以支持很多不同的 V ，而且會(huì)通過(guò)觀察者模式或 C 協(xié)助 V 完成信息的更新，但它也同樣存在劣勢(shì)：

1. 對(duì)于 V 相對(duì)單一或簡(jiǎn)單的情況而言，MVC 本身引入了更多的復(fù)雜性；

2. 更新的成本相對(duì)增加了，原本可以在一個(gè)方法中完成的更新要被分拆為 M/V/C 三類對(duì)象的協(xié)作；

?

(P499) “管道 - 過(guò)濾器”(Pipeline - Filters) 模式是一種通過(guò)組織一系列連續(xù)過(guò)濾條件完成既定處理的模式；

?

(P563) “高層模塊不應(yīng)該依賴于低層模塊，二者都應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。”

?

(P570) .NET 3.0 之后對(duì)于遠(yuǎn)程調(diào)用技術(shù)集中到 WCF 框架下；

?

(P574) WCF 其實(shí)在用面向?qū)ο蠡姆绞浇鉀Q面向服務(wù)的開(kāi)發(fā)問(wèn)題；

?

(P628) 在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中 (DDD : Domain Driven Design) 中，實(shí)現(xiàn)業(yè)務(wù)邏輯層主要有 Transcation Script、Domain Module 和 Table Module 三種模式；

?

(P644) 不兼容接口間適配器 (Adapter) 是個(gè)不錯(cuò)的途經(jīng)；

轉(zhuǎn)載于:https://blog.51cto.com/tianjing/907602

總結(jié)

以上是生活随笔為你收集整理的《设计模式 基于C#的工程化实现及扩展》 - 书摘精要的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。