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