單一職責原則
單一職責原則（srp），對於乙個類而言，應該僅有乙個引起它變化的原因。通俗的說，乙個類只能幹乙個事，只能承擔乙個職責。如果乙個類承擔的職責過多，等於把這些職責耦合在一起，這種耦合會導致設計十分的脆弱，當變化發生的時候，會遭到意想不到的破壞。
開放-封閉原則
開放封閉原則，簡稱開閉原則，指軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改。換句話說，對擴充套件開放，對更改封閉。但無論模組多麼的封閉，都會存在一些無法應對的變化。因此，設計人員必須對他設計的模組應該對哪種變化封閉做出選擇。
開閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的各種好處，如可維護、可復用、靈活性好等等。但不可以過度抽象，每個地方都抽象。
黎克特制代換原則
黎克特制代換原則，即子型別必須能夠替換掉他們的父型別。翻譯成白話就是乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類。也就是說在軟體裡面把父類都換成他的子類，程式的行為沒有變化。
依賴倒轉原則
依賴倒轉原則，即：a.高層模組不應該依賴低層模組。兩個都應該依賴抽象。b:抽象不應該依賴細節，細節應該依賴抽象。用大白話說就是，要針對介面程式設計，不要針對實現程式設計。
依賴倒轉原則可以說是物件導向設計的標誌，如果程式中所有的依賴關係都是終止於抽象類或介面，那就是物件導向的設計，反之就是過程化的設計了。
迪公尺特法則
迪公尺特法則，指如果兩個類不必直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個類。體現到我們的設計上，就是每個類都應該盡量降低成員的訪問許可權，即強調了低耦合。
解決的問題
裝飾模式，動態地給乙個物件新增一些額外的職責。當我們需要為程式新增新的功能的時候，我們把每個要裝飾的功能放在單獨的類中，然後讓這個類包裝原有的類，這樣就可以把類中的裝飾功能從類中刪除，簡化原有的類。也可以去除類中重複的裝飾邏輯。
類圖結構
在如上的類圖中，component定義了乙個物件介面，可以給這些物件動態地新增職責。concretecomponent定義了乙個具體的物件，也可以給這個物件新增一些職責。decorator類是裝飾抽象類，繼承了component，從外類來拓展component類的功能。但對於component來說，無需知道decorator的存在。concretedecorator就是具體的裝飾物件，起到給component新增職責的功能。
如下基本**：
component類
public abstract class componentconcretecomponent類
public class concretecomponent extends component
}
decorator類
public abstract class decorator extends component
@override
public void operation()}}
concretedecoratora類
public class concretedecoratora extends decortor
}
總的來說，裝飾模式可以動態的為已有功能新增更多的功能。這些功能多半只滿足一些只在特定情況下才會執行的特殊行為的需要。因此，為了減輕主類的負擔才有了裝飾模式的產生。但使用裝飾模式會使得查錯變的困難，因為這些物件看上去都很類似。
解決的問題
**模式，可以為其他物件提供一種**以控制對這個物件的訪問。通過**模式可以詳細控制訪問某個類或者某個物件的方法，在呼叫這個方法前做前置處理等等。這也是spring中的aop實現的原理。
類圖結構
如圖所示，subject類定義了proxy和realsubject的共用介面，這樣就可以在任何使用realsubject的地方都可以使用proxy。realsubject類代表proxy所代表的真實實體，proxy類可以儲存乙個引用使得**可以訪問實體，並提供乙個與subject的介面相同的介面，這樣**就可以用來替代實體。
**如下：
subject類
public abstract class subjectrealsubject類
public class realsubject extends subject
}
proxy類
public class proxy extends subject
realsubject.request();}}
**模式的應用十分廣泛，如遠端**、虛擬**、安全**等等。但**模式會造成系統設計中類的數量增加，且會使得系統的複雜度上公升。
大話設計模式筆記（二） 策略模式
商場收銀軟體，營業員根據客戶所購買的商品單價和數量，向客戶收費。普通實現 created by callmedevil on 2019 6 1.public class normaltest 計算總價 param price 單價 param num 數量 return private static...
《大話設計模式》學習筆記二》
做乙個商場收銀的小系統。剛開始程式設計的時候，沒有想到 的可維護性，因此編出來的程式只能是正常收費的情況。當商場打算搞 那該怎麼辦呢？只好重寫程式。再次寫這個程式的時候要考慮的代買的可維護性。我們考慮一下，商場無論怎麼搞 活動，不同的僅僅是收銀時的打折處理方法，而基本的計算總價方法是相同的，不同的打...
大話設計模式（二）
6.裝飾模式 動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。uml類圖關係 1 component物件抽象類 物件類 有乙個功能fun 2 decorator裝飾抽象類，繼承物件類 或物件抽象類 提供乙個最重要的setcomponent component com ...