原创 設計模式筆記9:抽象工廠

Abstract Factory 動機 經常面臨着“一系列相互依賴的對象工作”;同時,由於需求的變化,往往存在更多系列對象的創建工作。 如何應對這種變化?如何繞過常規的對象創建方法(new),提供一種“封裝機制”來避免客戶程序

原创 設計模式筆記20:組合模式

Composite 動機 客戶代碼過多地依賴於對象容器複雜的內部實現結構,對象容器內部實現結構(而非抽象結構)的變化 引起客戶代碼的頻繁變化,帶來了代碼的維護性、擴展性等弊端。 如何將”客戶代碼與複雜的對象容器結構“解耦?讓對

原创 設計模式筆記8:工廠模式

Factory Method “對象創建”模式 通過“對象創建”模式繞開new,來避免對象創建(new)過程中導致的緊耦合(依賴具體類),從而支持對象創建的穩定。它是接口抽象之後的第一步工作。 典型模式: Factory Me

原创 設計模式筆記14:門面模式

Façade “接口隔離”模式 在主件構建過程中,某些接口之間的依賴常常會帶來很多問題、甚至根本無法實現。採用添加一層間接(穩定)接口,來隔離本來互相緊密關聯的接口是一種常見的解決方案。 典型模式: Façade Proxy

原创 設計模式筆記3:模板方法

Template Method 重構獲得模式(Refactoring to Patterns) 設計模式的應用不宜先入爲主,一上來就使用設計模式是設計模式的最大誤用;沒有一步到位的設計模式,敏捷軟件開發提倡的是“Refactor

原创 設計模式筆記15:代理模式

Proxy 動機 在面向對象系統中,有些對象由於某種原因(比如對象創建的開銷很大,或者某些操作需要安全控制,或者需要進程外的訪問等), 直接訪問會給使用者、或者系統結構帶來很多麻煩。 如何在不失去透明操作對象的同事來管理/控制

原创 設計模式筆記10:原型模式

Prototype 動機 經常面臨這“某些結構複雜的對象”的創建工作;由於需求的變化,這些對象經常面臨着劇烈的變化,但是它們卻擁有比較穩定一致的接口。 如何應對這種變化?如何向“客戶程序(使用這些對象的程序)”隔離出“這些易變

原创 設計模式筆記1:設計模式簡介

李建鍾老師的視頻鏈接 23個設計模式 什麼是設計模式 1.可複用 2.面向對象 目標 管理變化,提高複用 什麼時候不用模式 代碼可讀性很差時 需求理解還很淺時 變化沒有顯現時 不是系統的關鍵依賴點 項目沒有複用價值時 項

原创 設計模式筆記13:享元模式

Flyweight 動機 採用純粹對象方案的問題在於大量細粒度的對象會很快充斥在系統中,從而帶來很高的運行時代價——主要指內存需求方面的代價。 如何在避免大量細粒度對象問題的同時,讓外部客戶程序仍然能夠透明地使用面向對象的方式

原创 設計模式筆記4:策略模式

Strategy 動機(Motivation) 在軟件構建過程中,某些對象使用的算法可能多種多樣,經常改變,如果將這些算法都編碼到對象中,將會使對象變得異常複雜;而且有時候支持不使用的算法也是一個性能負擔。 如何在運行時(Ru

原创 設計模式筆記11:構建器

Builder 動機 有時候面臨着“一個複雜對象”的創建工作,其通常由各個部分的子對象用一定的算法構成;由於需求的變化,這 個複雜對象的各個部分經常面臨着劇烈的變化,但是將它們組合在一起的算法卻相對穩定。 如何應對這種變化?如

原创 設計模式筆記12:單例模式

Singleton "對象性能"模式 面向對象很好地解決了“抽象”的問題,但是必不可免地要付出一定的代價,對於通常情況來講,面向對象的成本大都可以忽略不計。但是某些情況,面向對象所帶來的成本必須謹慎處理。 典型模式: SIng

原创 設計模式筆記2:面向對象設計原則

1. 依賴倒置原則(DIP) 高層模塊(穩定)不應該依賴於低層模塊(變化),二者都應該依賴於抽象(穩定) 抽象(穩定)不應該依賴於實現細節(變化) ,實現細節應該依賴於抽象(穩定) 目的:隔離變化,模塊分開 2. 開閉

原创 設計模式筆記6:裝飾模式

Decorator “單一職責”模式: 如果責任劃分不清晰, 使用繼承得到的結果往往是隨着需求的變化,子類急劇膨脹,同時充斥着重複代碼,這時候的關鍵是劃分責任 典型模式: Decorator Bridge 動機 在某些情

原创 設計模式筆記7:橋模式

Bridge 動機 由於某些類型的固有的實現邏輯,使得它們具有兩個變化的維度,乃至多個緯度的變化。 如何應對這種“多維度的變化”?如何利用面向對象技術來使得類型可以輕鬆地沿着兩個乃至多個方向變化,而不引入額外的複雜度? 模