設計模式物件導向六大原則

本文為讀書筆記以及乙個觀後理解寫下，有誤望能指出

簡單理解就是在乙個類中完成本類的職責而不要過多新增其他的職責，以乙個反例的載入器來理解

public class imageloader
//展示
dispalyimage()
downloadimage()
}

imageloader中除了載入功能之外，還加入了乙個對於快取的操作，耦合度過大。所以可以進行解耦就是將cache的功能提取出來，提供get、put方法給imageloader呼叫

public class imageloader
downloadimage()
}

public class imagecache()
put()
get()
}

將功能分開，具體分到每個類當中，與上述的第乙個例子區別就是職責分開了，當出現需要對imagecache修改的時候，imageloader並不會影響到，imageloader無須關注imagecache的細節。

定義就是對於擴充套件是開放的，而對於修改是封閉的。按字面理解就是盡量通過去繼承子類或者介面的而不是去修改原有的類，除非類出現錯誤才會去修改原類。這樣的目的是什麼？好處之一就是為了乙個穩定性，在乙個龐大的**系統修改一處**可能造成未知的錯誤，所以通過繼承原類去擴充套件可以保證穩定

上乙個單一原則的例子中我們定義了imagecache類預設為記憶體快取，那麼加入我們想要使用sd卡的快取，此時我們就得去修改已有的函式**，不安全也不穩定，那麼我們在設計**的時候，可以通過將imagecache寫成介面/抽象類，具體想要實現的有我們寫的**來實現

public inte***ce imagecache

public class memorycache implements imagecache
...}

public class imageloader
downloadimage()
}

可以看到我們需要不同的cache時，只需要實現介面即可快速擴充套件功能而不用在原有類去修改

這個原則跟第二個原則有些關係，黎克特制替換原則的原理是核心抽象，強調乙個快速替換上述的第二原則中可以快速替換imagecache為memory或者sdcache，而第二個原則主要強調開閉的關係

聽起來有點抽象，我個人的理解就是乙個類呼叫另乙個類去實現功能是，不要通過直接的呼叫，比如我們上面的imagecache，如果不是寫成介面而是乙個普通了，那麼就是直接呼叫，imagecache為具體細節實現，imageloader為呼叫類，類與類之間通過抽象類或者介面來實現依賴。說這麼多有點抽象，還是通過例子好理解點。

public class imageloader
...}

我們預設將memorycache當成imagecache，當需要改動時，通過setimagecache來改變cache,通過抽象來依賴

這個原則對於個人不知道理解是否正確，我的理解就是將一些類拆分成粒度更小的類，比如我們常用的fileoutputstream，我們試用完之後需要close，其實fileoutputstream實現了closeable介面，很多類都實現了這乙個介面，那麼我們就可以將其拆分出來，寫成工具類closeutils(closeable closeable)統一關閉介面，需要用是呼叫這個工具類就可以。

以上五個原則英文第乙個字幕剛好可以組成solid原則

終於來到這一節的最後乙個原則了，這個原則的理解：只與直接的朋友通訊，通俗來講乙個類只需知道自己需要使用的功能即可，不需要知道具體的實現細節。舉個栗子，我們租房通過中介，中介又去找屋主匹配。這個情況最直接了明，我們只需要知道想要什麼房子，報給中介，具體房子怎樣，合不合法（正規中介）即可，其他的細節由中介去理清楚，個人覺得更像是mvp模式。

我們繼續拿上面的載入器來舉例子，我們實現中有個快取器，到底是記憶體快取還是sd快取不用考慮，imageloader是「我們」，抽象imagecache是「中介」，具體memory或者sd怎麼實現我們並不需要去考慮，只需要具體「中介」去決定即可。

設計模式 物件導向六大原則

設計模式 物件導向六大原則

物件導向 六大原則

物件導向六大原則

相關推薦

設計模式物件導向六大原則

設計模式物件導向六大原則

物件導向六大原則