生活随笔
收集整理的這篇文章主要介紹了
设计模式:开篇
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
歡迎支持筆者新作:《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》,同時歡迎關注筆者的微信公眾號:朱小廝的博客。
歡迎跳轉到本文的原文鏈接:https://honeypps.com/design_pattern/quick_start/
??最近在整理設計模式這個系列,這里做一下全局的概括。本系列的文章對于初識設計模式的朋友也許不太適應,對于那些了解過或者使用過設計模式的人比較適應,本系列的文章對設計模式的關鍵點做了一個終結性的陳述,也列舉了相關例子方便理解和記憶,但是并沒有循序漸進的講解。譬如,在適配器模式中,博主闡述了適配器的定義、類圖、案例等,但是并沒有闡述類似“比如你買了一個港版的iphone6s,但是大陸的插座不并適合,需要一個轉接口,這個轉接口就是適配器”這樣的語句來更形象的講解相關內容。
??雖然關于設計模式的文章鋪天蓋地,但是博主還是想自己整理一下,符合自己思路的設計模式。最近看到一句話,非常有感觸,大概是這樣說的:堅持做自己懶得做卻正確的事,你就能得到別人想得到缺得不到的東西。
面向對象的設計原則
??熟記面向對象的設計原則可以更好的理解設計模式,對于面向對象的設計原則,各個版本的說法不一,有說五種的,有說六種的,但是基本就是下面七種原則的組合,這里全部羅列出來,加深一下印象(非斜體的在每個版本中都有)。
- SRP:單一職責原則,一個類應該僅有一個引起它變化的原因。Single Responsibility Principle
- OCP:開閉原則,講的是設計要對擴展有好的支持,而對修改要嚴格限制。Open Close Principle
- LSP:里氏替換原則,子類必須能夠替換基類,否則不應當設計為其子類。Liskov Substitution Principle
- DIP:依賴倒換原則,設計要依賴于抽象而不是具體化。Dependence Inversion Principle
- ISP:將打的接口打散成多個小接口。 Interface Segregation Principle
- LoD:迪米特法則,一個對象應當盡可能少的去了解其它對象。也就是一個關于如何松耦合的法則。Law of Demeter,也稱為最少只是原則LKP Least Knowledge Principle
- CARP:優先使用復合/聚合,而不是繼承。Composition Aggregation Principle
設計模式的分類
設計模式一共可以分為23種,3大類:
創建型
Factory Method(工廠方法)http://blog.csdn.net/u013256816/article/details/50975438Abstract Factory(抽象工廠)http://blog.csdn.net/u013256816/article/details/50975438Builder(建造者)http://blog.csdn.net/u013256816/article/details/50978024Prototype(原型)http://blog.csdn.net/u013256816/article/details/50981322Singleton(單例)http://blog.csdn.net/u013256816/article/details/50966882
結構型Adapter Class/Object(適配器)http://blog.csdn.net/u013256816/article/details/51000290Bridge(橋接)http://blog.csdn.net/u013256816/article/details/51000327Composite(組合)http://blog.csdn.net/u013256816/article/details/51009417Decorator(裝飾)http://blog.csdn.net/u013256816/article/details/51009449Facade(外觀)http://blog.csdn.net/u013256816/article/details/51009480Flyweight(享元)http://blog.csdn.net/u013256816/article/details/51009522Proxy(代理)http://blog.csdn.net/u013256816/article/details/51009592
行為型Interpreter(解釋器)http://blog.csdn.net/u013256816/article/details/51058049Template Method(模板方法)http://blog.csdn.net/u013256816/article/details/51018676Chain of Responsibility(責任鏈)http://blog.csdn.net/u013256816/article/details/51058075Command(命令)http://blog.csdn.net/u013256816/article/details/51058106Iterator(迭代器)http://blog.csdn.net/u013256816/article/details/51058234Mediator(中介者)http://blog.csdn.net/u013256816/article/details/51058254Memento(備忘錄)http://blog.csdn.net/u013256816/article/details/51244961Observer(觀察者)http://blog.csdn.net/u013256816/article/details/51245002State(狀態)http://blog.csdn.net/u013256816/article/details/51245024Strategy(策略)http://blog.csdn.net/u013256816/article/details/51245046Visitor(訪問者)http://blog.csdn.net/u013256816/article/details/51245073
各個模式之間的對比 http://blog.csdn.net/u013256816/article/details/51245096
類圖
??熟練的掌握類圖能夠方便理解和記憶設計模式。這里沿用了資料1中所陳述的內容。
??常見的有以下幾種關系:泛化(Generalization)、實現(Realization)、關聯(Association)、聚合(Aggregation)、組合(Composition)、依賴(Dependency)
泛化:是指一種繼承(extends)關系。在UML類圖中,用空心三角形+實線來表示,箭頭指向父類。
實現:一般來講實現(implements)是針對類與接口之間的關系而言的。在UML類圖中,用空心三角形+虛線來表示。
關聯:是一種擁有的關系,它使用一個類知道另一個類的屬性和方法。如:老師與學生,丈夫與妻子關聯可以是雙向的,也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭,單向的關聯有一個箭頭,箭頭指向被擁有者。(代碼體現:成員變量)
聚合:是整體與部分的關系,且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系,輪胎離開車依然存在。聚合關系是關聯關系的一種,是強的關聯關系;關聯和聚合在語法上無法區分,必須考察具體的邏輯關系。在UML類圖中,用帶空心菱形的實心線表示,菱形指向整體。(代碼體現:成員變量)
組合:是整體和部分的關系,但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關系,沒有公司就不存在部門。組合關系是關聯關系的一種,是比聚合關系還要強的關系,它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。在UML類圖中,用帶實心的菱形的實線表示,菱形指向整體。(代碼體現:成員變量)
依賴:是一種使用的關系,即一個類的實現需要另一個類的協助,所以要盡量不使用雙向的互相依賴。在UML類圖中,用帶箭頭的虛線表示,指向被使用者。(代碼體現:局部變量、方法的參數或者對靜態方法的調用)
各個關系的強弱順序:泛化=實現>組合>聚合>關聯>依賴。
參考資料
《UML類圖幾種關系的總結》
歡迎跳轉到本文的原文鏈接:https://honeypps.com/design_pattern/quick_start/
歡迎支持筆者新作:《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》,同時歡迎關注筆者的微信公眾號:朱小廝的博客。
總結
以上是生活随笔為你收集整理的设计模式:开篇的全部內容,希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯,歡迎將生活随笔推薦給好友。