蔡學鏞老師翻譯的這本書，真的讓我愛不釋手，獲益良多
在一邊看書的同時，將裡面各章節末的要點整理打下來，方便日後查閱。
提醒：
在設計模式中，所謂的『實踐一個介面』並『不一定』表示『寫一個類別，再以implement關鍵字以實踐某個Java介面』。『實踐一個介面』泛指『實踐某個超型態(可以是類別或介面)的某個方法』。(P117)
OO守則：
1.找出程式中可能需要更動之處，把他們獨立出來，不要和那些不需要更動的程式碼混在一起(P09)
(把會變動的部分取出並封裝起來，以便以後可以輕易的擴充此部分，而不影響不需要更動的其他部分)
2.寫程式是針對介面而寫，而不是針對實踐方式而寫(P11)
3.多用合成，少用繼承(P23)
4.設計時，盡量盡量讓需要互動的物件之間關係鬆綁(P53)
5.類別應該開放，以便擴充；應該關閉，禁止修改(P86)
6.依賴抽象類別，不要依賴具象類別(P139)
==>顛覆依賴守則(dependency Inversion Princlple)
==>不要讓高階元件依賴低階元件，而且不管高階或低階元件，二者都應該相依於抽象類別。
==>所謂高階元件，是由其他低偕元件定義其類別的行為。
以下方針能避免再oo設計中，違反顛覆相依守則：(P143)
A.變數不可以持有具像類別的參考。
如果使用new，就會持有具像類別的參考。改用工廠避開這樣的作法。
B.不要讓類別繼承字句像類別。
如果繼承自具像類別，就會依賴具像類別，請繼承自一個抽象(介面或抽象類別)。
C.不要讓次類別中的方法推翻(override)超類別中的方法。
如果推翻超類別的實踐方法，那麼超類別就不是一個真正適合被繼承的抽象。超類別中所實踐的方法，應該由所有次類別共享。
7.認識極少化守則：只和你的『密友』談話。(P265)
當你正在設計一個系統，不管是任何物件，都要注意他所互動的類別有哪些，並注意他和這些類別如何互動。
這個守則希望我們在設計中，不要讓太多類別綑綁在一起，免的修改系統中一部分，會影響到其他部分。如果許多類別之間互相依賴，就會變成一個易碎的系統，需要花許多成本維護，也因為太過於複雜而不容易被了解。
如何不要得到太多朋友以及有影響力的物件：(P266)
此守則提供了一些方針：
以某個物件而言，此物件的方法定義內，只應該引用物件的某些方法，而這些方法必須屬於：
A.該物件本身
B.被當作方法的參數而傳遞進來的物件
C.此方法所建立或實體化的任何物件
D.物件的任何元件
請注意，這些方針告訴我們，如果某物件是從其他的方法中所傳回來的，不要呼叫該物件的方法！
把『元件』想像成是被實體變數所參考到的任何物件，換句話說，把這想像成是『有一個』(HAS-A)關係。
8.好萊鎢守則：別呼叫我們，我們會呼叫你。(P296)
9.一個類別應該只具有一個改變的理由。(P339)
OO模式
策略模式(Strategy 模式)-定義了演算法家族，個別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變動不會影響到演算法的程式。
觀察者模式(Observer 模式)-在物件之間定義一對多的關係，如此一來，當一個物件的狀態改變，期關係物件都會收到通知，並自動更新。
裝飾者模式(Decorator 模式)-動態地將責任加諸於物件上。想要擴充功能，裝飾者提供有別於繼承的另一個選擇。
工廠方法模式(Simple Factory 模式)-定義了一個建立物件的介面，但由次類別決定實體化的類別為何。工廠方法讓類別將提體化的動作，交由次類別進行。
抽象工廠模式(Abstract Factory 模式)-提供了一個介面，建立相關或相依物件之家族，而不須明確指定具象類別。
獨體模式(Singleton 模式)-確保一個類別只有一個實體，並給他一個存取的全域點(golbal point)。當需要確保程式中的某個類別只有一個實體，就採用獨體模式吧！
命令模式(Command 模式)-將請求封裝成物件，以便使用不同的請求、佇列、或者日誌，參數化其他物件。命令模式也支援可復原的作業。當需要將發出請求的物件和執行請求的物件之間鬆綁的時候，你就該使用命令模式。
轉接器模式(Adapter 模式)-將一個類別的介面，轉換成另一個介面以供客戶使用。轉接器讓原本介面不相容的類別可以合作無間。
表象模式(Facade 模式)-提供了一個統一的介面，用來存取次系統中的一群介面。表象定義了一個較高層次的介面，讓次系統更容易使用。
表象不只是簡化了介面，也將客戶從元件的次系統中鬆綁出來。
表象與轉接器之差異：(P260)
表象與轉接器二種模式的差異，不在於他們『包裝』了幾個類別，而是在於他們的目的。轉接器模式的目的是，改變介面符合客戶的期望，而表象模式的目的是，提供次系統的一個簡化介面。
表象以及轉接器可以包裝許多類別，但是表象的目的是要簡化介面，而轉接器的目的是將介面轉換成不同介面。
樣板模式(Template Method 模式)-將一個演算法的骨架定義在一個方法中，而演算法本身會用到的一些方法，則是定義在次類別中。樣板方法讓次類別在不改變演算法架構的情況下，重新定義演算法中的某些步驟。
反覆器模式(Iterator 模式)-讓我們能夠取得一個聚集內的每一個元素，而不需要此聚集將其實踐方式暴露出來。
合成模式(Composite 模式)-允許你將物件合成樹狀結構，呈現『部分/整體』的階層關係。合成能讓客戶程式碼以一致的方式處理個別物件，以及合成的物件。利用合成，客戶程式碼能一視同仁地對待個別的物件，以及物件合成的結果。
狀態模式(State 模式)-允許物件隨著內在的狀態改變而改變行為，好像物件的類別改變了一樣。
代理人模式(Proxy 模式)-讓某個物件具有一個替身，藉以控制外界對此物件的接觸。使用代理人模式建立代表物件，讓代表物件控制某物件的存取，被代理的物件可以是遠端的物件，建立成本高的物件，或者需要安全控管的物件。
相關網路資源：
Design Patterns In C# and VB.NET
沒有留言:
張貼留言