在面向物件的開發中，主要遵循的有以下6個設計原則：

單一職責 ，開放封閉 ，里氏代換，依賴倒轉，迪米特法則，合成/聚合複用

下面將具體介紹這些設計原則：

單一職責原則：就一個類而言，應該僅有一個引起它發生變化的原因

如果一個類的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱這個或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，這種高耦合會導致意想不到的變化

開放封閉原則:軟體實體(類，模組，函式等等)應該可以擴充套件，但是不能修改

面對需求的時候，對程式的改動是通過增加新的程式碼來完成的，而不是通過對原始碼的改變來完成，對於原始碼的改變很麻煩，可能會導致意想不到的錯誤

開放封閉原則是面向物件設計的核心所在，遵循這個原則，實現了可維護，可擴充套件，可複用，靈活性好，開發人員應該進隊程式中呈現出頻繁變化的那些部分作出抽象，但是也不能可以地對每一個部分進行抽象，拒絕不成熟的抽象一樣很重要

個人理解：簡單工廠模式並不是屬於23中設計模式之一，主要就是因為簡單工廠模式不符合開放封閉的原則，在類裡面增加switch...case語句，當有新的功能或者是類的時候，就要修改該工廠類，程式碼的可維護性減低了

里氏代換原則：子型別必須能夠替換掉他們的父型別

只有當子類可以替換到父類，軟體單位的功能不受到影響的時候，父類才能真正被複用，而子類也能夠在父類的基礎上增加新的行為

如果沒有里氏代換原則，我們在開發的時候如果改變了子類的行為，同時對父類產生了影響，這樣你要修改子類，也就必須要修改父類了。

依賴倒轉原則：也叫依賴倒置原則，其內容如下：

A：高層模組不應該依賴底層模組，兩個都應該抽象

B：抽象不應該依賴細節，細節應該依賴抽象

倒轉，假如使用者的需求需要改變，軟體開發的時候你用的是db2資料庫，但是最後要改為mysql資料庫，由於高層的模組依賴的是底層的模組，這就使得底層模組也要做修改。但是如果高層模組依賴的是介面或者是抽象類的話，因為介面和抽象類是不變的，所以如果你要更改資料庫的話，就不怕出現混亂，A和B兩個說的都是這樣的意思。因為依賴的是抽象類或者介面，有里氏代換規則可以知道，子類的變化對於父類造不成影響。

針對上面的例子，我們可以做一個抽象的資料庫的類，讓db2繼承這個抽象類，加入現在要換為mysql資料庫，只要讓mysql去繼承這個類就可以，不管用哪個資料庫，我們都建立的是抽象資料類的引用，用它去指向你要訪問的類就ok了

迪米特法則：如果兩個類之間不必發生彼此直接通訊，那麼這兩個類就不應當發生直接的相互引用。如果其中一個類需要呼叫另一個類的某個方法的話，可以通過第三者轉發這個呼叫

對於這個原則，我是這樣理解的，兩個類之間相互知道了解，就是將一個類直接暴露給了另外一個類，這樣子違反了資訊的隱藏。如果多個類之間需要兩兩發生呼叫的話，那麼就需要呼叫者知道被呼叫這的全部資訊，這是我們可以通過一箇中介來轉發需要通訊的兩個類之間的請求，所有的類，只需要將自己暴露給中介就可以了，不需要給被呼叫者，這樣做簡化了程式碼，這也就是設計模式中的中介者模式

這樣降低了類與類之間的耦合性，符合我們提倡的低耦合的觀點，耦合性越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及

合成/聚合複用原則：儘量使用合成/聚合，儘量不要使用類繼承

這樣的好處有助於保持每個類被封裝，並被集中在單個任務上，這樣類和繼承層級會保持較小的規模，並且不太可能增長為不可控制的龐然大物

拿橋接模式來舉例，加入不同的手機品牌，有不同的軟體，每種軟體都要安裝在不同的手機上面，如果這個時候用繼承的話，每個具體手機品牌繼承抽象類手機品牌，然後在每個手機品牌下面都有每個軟體的使用，這樣一個軟體被實現了很多次，每個手機品牌都可以對其實現，如果我們要新增加一個軟體的話，每個具體的手機品牌就又要分別實現，這樣違反了可維護性。

這時候我們可以讓軟體成為手機品牌的一個組成部分，他們之間的關係是組合關係，只需要寫一個具體的軟體抽象類，然後讓每個具體的軟體去繼承這個抽象類，這個時候如果要增加軟體實現類，只需要增加一個具體的實現類就可以了

以上是我學習《大話設計模式》對於面向物件設計所遵循的六個設計原則的總結，希望對您有用。