不少人應該據說過設計模式(Design pattern),又或多或少的看過或用過設計模式,可是實際用在開發過程當中總有點愛莫能助的感受。那確定是對設計模式的理解有少量誤差或者不夠深刻。先不談某種具體的模式,先來看看什麼是設計模式?編程
從概論結合實際場景分析設計模式
設計模式是一套代碼設計「經驗的總結」。項目中「合理的」運用設計模式能夠「巧妙的解決不少問題」。學習
經驗的總結:抱着「代碼虐我千百遍,我待代碼如初戀」的心態,最終得出來的「套路」。spa
合理的:要對設計模式的使用場景有必定的認識後才使用,「不要濫用」。如:輸出一句「hello world」,非要強行給加上各類模式。
問:「爲何」,答:「總感受少了模式!」。設計
巧妙的解決了不少問題:被普遍應用的緣由。htm
爲何要提倡「Design Pattern呢?根本緣由是爲了代碼複用,增長可維護性。那麼怎麼才能實現代碼複用呢?對象
1988年,勃蘭特·梅耶(Bertrand Meyer)在他的著做《面向對象軟件構造(Object Oriented Software Construction)》中提出了開閉原則,它的原文是這樣:「Software entities should be open for extension,but closed for modification」。繼承
意思:軟件模塊應該對擴展開放,對修改關閉。接口
舉例:在程序須要進行新增功能的時候,不能去修改原有的代碼,而是新增代碼,實現一個熱插拔的效果(熱插拔:靈活的去除或添加功能,不影響到原有的功能)。ip
目的:爲了使程序的擴展性好,易於維護和升級。
意思:里氏代換原則是繼承複用的基石,只有當衍生類能夠替換掉基類,軟件單位的功能不受到影響時,基類才能真正被複用,而衍生類也可以在基類的基礎上增長新的行爲。
舉例:球類,本來是一種體育用品,它的衍生類有籃球、足球、排球、羽毛球等等,若是衍生類替換了基類的本來方法,如把體育用品改爲了食用品(那麼軟件單位的功能受到影響),就不符合里氏代換原則。
目的:對實現抽象化的具體步驟的規範。
意思:針對接口編程,而不是針對實現編程。
舉例:以計算機系統爲例,不管主板、CPU、內存、硬件都是在針對接口設計的,若是針對實現來設計,內存就要對應到針對某個品牌的主板,那麼會出現換內存須要把主板也換掉的尷尬。
目的:下降模塊間的耦合。
使用多個隔離的接口,比使用單個接口要好。
舉例:好比:登陸,註冊時屬於用戶模塊的兩個接口,比寫成一個接口好。
目的:提升程序設計靈活性。
1987年秋天由美國Northeastern University的Ian Holland提出,被UML的創始者之一[Booch]等普及。後來,由於在經典著做《 The Pragmatic Programmer》而廣爲人知。
意思:一個實體應當儘可能少的與其餘實體之間發生相互做用,使得系統功能模塊相對獨立。
舉例:一個類公開的public屬性或方法越多,修改時涉及的面也就越大,變動引發的風險擴散也就越大。
目的:下降類之間的耦合,減小對其餘類的依賴。
該原則由羅伯特·C·馬丁(Robert C. Martin)於《敏捷軟件開發:原則、模式和實踐》一書中給出的。馬丁表示此原則是基於湯姆·狄馬克(Tom DeMarco)和Meilir Page-Jones的著做中的內聚性原則發展出的。
意思:一個類只負責一個功能領域中的相應職責,或者能夠定義爲:就一個類而言,應該只有一個引發它變化的緣由。
舉例:該原則意思簡單到不須要舉例!
目的:類的複雜性下降,可讀性提升,可維護性提升。
剛入行的時候,在想什麼樣的代碼是好代碼?看到不少前輩的文字都說好的代碼要符合「高內聚,低耦合」,可是我聽到這樣的解釋,是這樣的
而如今對設計模式有了必定程度上的學習,感受懂了一些,小夥伴們大家學會了嗎?
內聚是從功能角度來度量模塊內的聯繫,一個好的內聚模塊應當剛好作一件事。它描述的是模塊內的功能聯繫;
耦合是軟件結構中各模塊之間相互鏈接的一種度量,耦合強弱取決於模塊間接口的複雜程度、進入或訪問一個模塊的點以及經過接口的數據。