您好,登錄后才能下訂單哦!
本文小編為大家詳細介紹“軟件開發基礎之設計模式分為哪些類型”,內容詳細,步驟清晰,細節處理妥當,希望這篇“軟件開發基礎之設計模式分為哪些類型”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。
無論是在我們學習設計模式的過程中,還是日常的開發過程中,都要遵循一套統一的軟件設計原則。
在常見的設計原則中,一共是7 種設計原則,它們分別為開閉原則、里氏替換原則、依賴倒置原則、單一職責原則、接口隔離原則、迪米特法則和合成復用原則。
各種各樣的原則最終目的只有一句話,也是軟件開發人員聽過的最多的一句話:高內聚、低耦合,提高復用性、可擴展性、可維護性。
設計原則 | 一句話歸納 | 目的 |
---|---|---|
開閉原則 | 對擴展開放,對修改關閉 | 降低維護帶來的新風險 |
依賴倒置原則 | 高層不應該依賴低層,要面向接口編程 | 更利于代碼結構的升級擴展 |
單一職責原則 | 一個類只干一件事,實現類要單一 | 便于理解,提高代碼的可讀性 |
接口隔離原則 | 一個接口只干一件事,接口要精簡單一 | 功能解耦,高聚合、低耦合 |
迪米特法則 | 不該知道的不要知道,一個類應該保持對其它對象最少的了解,降低耦合度 | 只和朋友交流,不和陌生人說話,減少代碼臃腫 |
里氏替換原則 | 不要破壞繼承體系,子類重寫方法功能發生改變,不應該影響父類方法的含義 | 防止繼承泛濫 |
合成復用原則 | 盡量使用組合或者聚合關系實現代碼復用,少使用繼承 | 降低代碼耦合 |
這些原則在我們開發過程中或多或少的都有體現,比如在我們的項目中業務層總是定義Service接口,在Impl中實現具體的邏輯,很多開發只是照葫蘆畫瓢,卻并不知道為什么要這樣做,結合開發原則讀者可以仔細想一下為什么要這樣做。
還有一個典型的用法,我們定義的實體類的成員變量,總是用private修飾,然后定義get和set方法去操作這些成員變量,那為什么不直接把成員變量定義public,直接操作成員變量呢。
軟件設計原則在我們的開發中處處體現,在一些代碼習慣上多思考,做到知其然知其所以然。
在設計模式學習過程中可以查閱該文檔,學習每個設計模式時,對于他的作用和分類能做到心中有數。
創建型模式的主要關注點是“怎樣創建對象?”,它的主要特點是“將對象的創建與使用分離”。
單例(Singleton)模式:某個類只能生成一個實例,該類提供了一個全局訪問點供外部獲取該實例,其拓展是有限多例模式。
原型(Prototype)模式:將一個對象作為原型,通過對其進行復制而克隆出多個和原型類似的新實例。
工廠方法(FactoryMethod)模式:定義一個用于創建產品的接口,由子類決定生產什么產品。
抽象工廠(AbstractFactory)模式:提供一個創建產品族的接口,其每個子類可以生產一系列相關的產品。
建造者(Builder)模式:將一個復雜對象分解成多個相對簡單的部分,然后根據不同需要分別創建它們,最后構建成該復雜對象。
結構型模式描述如何將類或對象按某種布局組成更大的結構。它分為類結構型模式和對象結構型模式,前者采用繼承機制來組織接口和類,后者釆用組合或聚合來組合對象。
代理(Proxy)模式:為某對象提供一種代理以控制對該對象的訪問。即客戶端通過代理間接地訪問該對象,從而限制、增強或修改該對象的一些特性。
適配器(Adapter)模式:將一個類的接口轉換成客戶希望的另外一個接口,使得原本由于接口不兼容而不能一起工作的那些類能一起工作。
橋接(Bridge)模式:將抽象與實現分離,使它們可以獨立變化。它是用組合關系代替繼承關系來實現的,從而降低了抽象和實現這兩個可變維度的耦合度。
裝飾(Decorator)模式:動態地給對象增加一些職責,即增加其額外的功能。
外觀(Facade)模式:為多個復雜的子系統提供一個一致的接口,使這些子系統更加容易被訪問。
享元(Flyweight)模式:運用共享技術來有效地支持大量細粒度對象的復用。
組合(Composite)模式:將對象組合成樹狀層次結構,使用戶對單個對象和組合對象具有一致的訪問性。
行為型模式用于描述程序在運行時復雜的流程控制,即描述多個類或對象之間怎樣相互協作共同完成單個對象都無法單獨完成的任務,它涉及算法與對象間職責的分配。
行為型模式分為類行為模式和對象行為模式,前者采用繼承機制來在類間分派行為,后者采用組合或聚合在對象間分配行為。由于組合關系或聚合關系比繼承關系耦合度低,滿足“合成復用原則”,所以對象行為模式比類行為模式具有更大的靈活性。
模板方法(Template Method)模式:定義一個操作中的算法骨架,將算法的一些步驟延遲到子類中,使得子類在可以不改變該算法結構的情況下重定義該算法的某些特定步驟。
策略(Strategy)模式:定義了一系列算法,并將每個算法封裝起來,使它們可以相互替換,且算法的改變不會影響使用算法的客戶。
命令(Command)模式:將一個請求封裝為一個對象,使發出請求的責任和執行請求的責任分割開。
職責鏈(Chain of Responsibility)模式:把請求從鏈中的一個對象傳到下一個對象,直到請求被響應為止。通過這種方式去除對象之間的耦合。
狀態(State)模式:允許一個對象在其內部狀態發生改變時改變其行為能力。
觀察者(Observer)模式:多個對象間存在一對多關系,當一個對象發生改變時,把這種改變通知給其他多個對象,從而影響其他對象的行為。
中介者(Mediator)模式:定義一個中介對象來簡化原有對象之間的交互關系,降低系統中對象間的耦合度,使原有對象之間不必相互了解。
迭代器(Iterator)模式:提供一種方法來順序訪問聚合對象中的一系列數據,而不暴露聚合對象的內部表示。
訪問者(Visitor)模式:在不改變集合元素的前提下,為一個集合中的每個元素提供多種訪問方式,即每個元素有多個訪問者對象訪問。
備忘錄(Memento)模式:在不破壞封裝性的前提下,獲取并保存一個對象的內部狀態,以便以后恢復它。
解釋器(Interpreter)模式:提供如何定義語言的文法,以及對語言句子的解釋方法,即解釋器。
UML類圖摘抄自大話設計模式,我目前見過最好的一張圖,便于讀者理解。
在面向對象的世界中,包含了對象和接口,UML類圖主要是能表達出來對象和接口的表現和他們的關系。
對象和接口都是采用矩形框表示,因為對象包含類名、成員變量、成員方法所以用三層來表示,接口沒有成員變量,所以采用兩層來表示,為了更易于區分在接口名上《interface》,另外,抽象類用斜體表示。成員變量均有關鍵詞修飾,+代表public、-代表private、#代表protected
接下來說明類與類、接口與類之間關系的表達。
繼承,空心三角形+實線
實現接口,空心三角形+虛線
關聯,實線。企鵝和氣候。
聚合,菱形+實現箭頭。雁群和大雁。
依賴,虛線箭頭。動物依賴水和氧氣才能生存。
讀到這里,這篇“軟件開發基礎之設計模式分為哪些類型”文章已經介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會,如果想了解更多相關內容的文章,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。