03-設計模式教學課件

常見面對對象設計原則引言設計原則是思想上的指導設計模式是實現上的手段設計模式是設計原則的具體表達在實際開發(fā)中，很少做到完全遵守，總是在有意無意的違反一些或者局部原則設計是一種危急的平衡藝術單一職責原則(SRP)

SingleResponsibilityPrinciple拍攝UFO單一職責原則就一個類而言，應當僅有一個引起它變化的緣由〔職責〕。假設一個類擔當的職責過多，就等于把這些職責耦合在一起，一個職責的變化可能會減弱或者抑制這個類完成其他職責的力氣。這種耦合會導致脆弱的設計，當變化發(fā)生時，設計會患病到意想不到的破壞難點在于如何區(qū)分職責、職責的粒度問題軟件設計真剛要做的內容，就是覺察職責并把那些職責相互分別。假設你能夠想到多于一個的動機去轉變一個類，那么這個類就具有多于一個的職責，就應當考慮類的職責分別。開放-封閉原則〔OCP原則〕

Open-ClosedPrinciple開放-封閉原則Open-ClosedPrinciple原則講的是：一個軟件實體應當對擴開放放，對修改關閉。需要考慮：怎樣的設計才能面對需求的轉變卻可以保持相對穩(wěn)定，從而使得系統可以在第一個版本以后不斷推出新的版本。面對需求，對程序的改動是通過增加新的代碼進展的，而不是更改現有代碼。例如第一章程序關鍵合理地抽象、分別出變化與不變化的局部，為變化的局部預留下可擴展的方式。例如：鉤子方法或是動態(tài)組合對象等要完全遵守開閉原則是不行能的，也沒這個必要。適當的抽象可以提高系統的靈敏性、使其可擴展、可維護；過度抽象，會大大增加系統的簡潔程度。例子：招安招安之法的關鍵便是不允許更改現有的秩序，但允許將被招安者納入現有秩序中，從而擴展了這一秩序。用面對對象的語言來講，不允許更改的是系統的抽象層，而允許更改的是系統的實現層。里氏代換原則

LiskovSubstitutionPrinciple使得開放-封閉成為可能里氏代換原則里氏代換原則子類型(subtype)必需能夠替換它們的基〔父〕類型?！沧宇惪梢砸愿割惖纳矸菹拧臣僭O鳥是會飛的，企鵝不會飛，企鵝是鳥嗎？？？由于子類型的可替換性才使得使用父類型的模塊在無需修改的狀況下就可以擴展。因此是實現開閉原則的前提之一依靠倒轉〔置〕原則(DIP)

DependenceInversionPrinciple依靠倒轉原則依靠倒轉〔置〕〔DependenceInversionPrinciple〕原則講的是：要依靠于抽象，不要依靠于具體。簡潔的說，依靠倒轉原則要求客戶端依靠于抽象耦合。原則表述：抽象不應當依靠于具體實現；具體實現應當依靠于抽象；高層模塊不應當依靠于底層模塊，二者都應當依靠于抽象要針對接口編程，不針對實現編程。修電腦得到的啟發(fā)強內聚、松耦合由于PC易插撥的方式，那么不管哪一個出問題，都可以在不影響別的部件的前題下進展修改或替換?！币揽康罐D原則要針對接口編程，不要對實現編程，無論主板、CPU、內存、硬盤都是在針對接口編程，假設針對實現編程，那就會消逝換內存需要把主板也換了的犯難常見錯誤層次化調用的時候，應當是高層調用“底層所擁有的接口”，這是一典型的誤會。一般高層包含對業(yè)務功能的處理和業(yè)務策略選擇，應當被重用，是高層模塊去影響底層的具體實現。這個底層的接口應當是由高層提出的，然后由底層實現，即底層的接口的全部權在高層模塊，是一種全部權的倒置反面例子缺點：耦合太嚴密，Light發(fā)生變化將影響ToggleSwitch。解決方法一：將Light作成Abstract，然后具體類繼承自Light。優(yōu)點：ToggleSwitch依靠于抽象類Light，具有更高的穩(wěn)定性，而BulbLight與TubeLight繼承自Light，可以依據“開放－封閉”原則進展擴展。只要Light不發(fā)生變化，BulbLight與TubeLight的變化就不會涉及ToggleSwitch。缺點：假設用ToggleSwitch把握一臺電視就很困難了?？偛荒茏孴V繼承自Light吧。解決方法二：優(yōu)點：更為通用、更為穩(wěn)定。結論：使用傳統過程化程序設計所創(chuàng)立的依靠關系，策略依靠于細節(jié)，這是糟糕的，由于策略受到細節(jié)轉變的影響。依靠倒置原則使細節(jié)和策略都依靠于抽象，抽象的穩(wěn)定性預備了系統的穩(wěn)定性。HollywoodPrinciple：don”tcallus,we”llcallyou合成/聚合復用原則要盡量使用合成/聚合，而不是繼承關系到達復用的目的。

合成/聚合原則就是在一個新的對象里面使用一些已有的對象，使之成為新對象的一局部；新的對象通過向這些對象的委派到達復用已有功能的目的。FavorCompositionOverInheritance接口隔離原則〔ISP〕接口隔離原則接口隔離原則〔InterfaceSegregationPrinciple〕講的是：使用多個特地的接口比使用單一的總接口要好。換而言之，從一個客戶類的角度來講：一個類對另外一個類的依靠性應當是建立在最小接口上的。過于臃腫的接口是對接口的污染。不應當強迫客戶依靠于它們不用的方法。實現方法：使用多重繼承分別接口

迪米特法則〔LoD〕迪米特法則〔LawofDemeter或簡寫LoD〕又叫最少學問原則〔LeastKnowledgePrinciple或簡寫為LKP〕假設兩個類不必彼此直接通信，那么這兩個類就不應當發(fā)生直接的相互作用。假設其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發(fā)這個調用。也就是說，一個對象應當對其它對象有盡可能少的了解。其它表述只與你直接的朋友們通信不要跟“生疏人”說話每一個軟件單位對其它的單位都只有最少的學問，而且局限于那些與本單位親切相關的軟件單位。迪米特法則其根本思想，是強調了類之間的松耦合。類之間的耦合越弱，越有利于復用，一個處于弱耦合的類被修改，不會對有關系的類造成涉及。信息的隱蔽促進了軟件的復用。以史為鑒使民無知

《老子》第三章曰：“是以圣人之治，虛其心，實其腹，弱其志，常使民無知無欲?！笔贡弧敖y治”的對象“愚昧”化，處于“無知”的狀態(tài)，可以使“統治”的本錢降低。所謂“最少學問“原則，實際上便是老子的“使民無知“的統治之術。不相往來

《老子》云：“小國寡民……鄰國相望，雞犬之聲相聞，民至老死，不相往來?！睂⒈唤y治的對象隔離開來，使它們沒有直接的通信，可以到達分化瓦解，繼而分而治之的效果。迪米特法則與老子的“不相往來“的統治之術不謀而合。單一職責原則就一個類而言，應當僅有一個引起它變化的緣由。開放-封閉原則一個軟件實體應當對擴開放放，對修改關閉里氏代換原則