java23種設計模式及其源代碼演示實現

博主在CSDN已有三年,之前一直在看貼,受益頗多,不可多得的一個良好的學習平臺,這一次,博主給大家分享一份傳說中的java設計模式,源代碼與其實現全部都有,希望有助于大家提高開發能力
全文代碼全部手敲,不會存在侵權問題,純原創
歡迎轉載,但請附明出處
以下請欣賞全文:文字有點多,因為十分詳細

---

java23種設計模式

1、設計模式是人們在面對同類型軟件工程設計問題所總結出的一些有用經驗。模式不是代碼，而是某類問題的通用設計解決方案
2、4人組Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides總結寫了《設計模式》
3、設計模式的優點和用途
4、學習設計模式最好的方式：在你的設計和以往的工程里尋找何處可以使用它們
5、設計模式的本質目的是使軟件工程在維護性、擴展性、變化性、復雜度方面成O(N)
6、OO是原則，設計模式是具體方法、工具

-------------------------------- 特別說明,以下案例皆是主類,將代碼down下食用效果更佳! --------------------------------

類圖圖例:

Person1--eat() 代表Person類下面有一個eat() 方法1--eat(a,b,c) 代表Person類下面有一個eat方法,帶3個參數1__name __代表屬性,Person下面有name屬性-1__name __屬性私有化1--Student Person類下面有Student內部類2__name Student類下有name屬性-->1--Student Person類有子類Student,不在同一個文件2--run() 子類Student有run方法

策略模式01

1.分析項目中變化與不變部分
2.多用組合少用繼承;用行為類組合,而不是行為的繼承.更有彈性
案例:鴨子,不同種類的鴨子具有不同的組合行為
策略模式案例

觀察者模式02

1.多對一的依賴關系,Subject
2.觀察者注冊,移除,通知
3.java內置觀察者,Observable是類不是接口,不能多重繼承,具體如下:
案例:天氣預報項目,不同的公告板顯示不同的公告內容
觀察者模式案例
java內置觀察者案例
傳統模式案例
傳統模式存在問題:一個需求新建一個變量,擴展性差,見傳統模式

裝飾者模式03

裝飾者模式：動態的將新功能附加到對象上。在對象功能擴展方面，它比繼承更有彈性。
對于源有的代碼,不進行修改,維護方便

咖啡館訂單項目:傳統面向對象開發,超類擴展,新調料,新單品,各自兩兩組合,類爆炸
new 單品() new Milk(order) …
裝飾者模式案例
java內置裝飾者案例

單例模式04

有些對象只需要一個:線程池,緩存,硬件設備等
如果多個實例會有造成沖突,結果的不一致性等問題
確保類只有一個實例,同時又有全局訪問點

構造器私有化
多線程問題及優化
案例:巧克力工廠
單例模式案例

工廠模式05

pizza項目:有準備,烘焙,切割,打包4個步驟,要方便pizza品種的擴展,便于維護,運行同時也能擴展
傳統模式:運行時,增加pizza品種,需要修改類,不滿足運行同時擴展要求
傳統模式案例

簡單工廠模式:對象的實例化部分提取出來放入工廠類,滿足了運行同時擴展要求
但仍然有些問題:店鋪擴展,A地一個工廠 B地一個工廠…100個地方需要100個工廠,每個工廠的pizza種類文化均不同

public class SimplePizzaFactory {public Pizza CreatePizza(String ordertype) {Pizza pizza = null;if (ordertype.equals("cheese")) {pizza = new CheesePizza(); //多地工廠,B地pizza為CCPizza,則100個工廠需要100個不同的類} else if (ordertype.equals("greek")) {pizza = new GreekPizza();} else if (ordertype.equals("pepper")) {pizza = new PepperPizza();}return pizza;} }

簡單工廠模式案例

工廠方法模式設計方案:將pizza項目里的pizza對象實例化功能抽象成抽象方法,在不同加盟店具體實現功能

工廠方法模式案例

抽象工廠模式:定義了一個接口用于創建相關或有依賴關系的對象族,而無需明確指定具體類
工廠抽象成接口,指定工廠接入,子工廠與工廠無需在類里面直接修改代碼增加變量,代碼復用極高
依賴抽象原則:
1.變量不要持有具體類的引用
2.不要讓類繼承自具體類,要繼承自抽象類或接口
3.不要覆蓋基類中已實現的方法
抽象工廠模式案例

命令模式06

家電自動化遙控器API項目:背景:一個遙控器兩排按鈕,如圖示:
● ○
● ○
● ○
● ○
● ○
左邊●這一豎排自上而下分別控制燈,音響,增加音量…
右邊○這一豎排自上而下分別控制關燈,關閉音響,減小音量…
要求自動化遙控器:擴展性好(當有新設備進來:掃地機器人,也接入該遙控器,要求極少量修改遙控器代碼),維護性好

傳統模式方案問題:當新設備進來,代碼耦合度極高,維護困難
傳統模式案例
傳統模式存在的問題

命令模式:將請求,命令,動作等封裝成對象,這樣可以讓項目使用這些對象來參數化其他對象.使得命令的請求者和執行者解耦
命令模式案例
宏命令,即一鍵功能

適配器模式07

插頭與插座,汽車點煙器轉usb充電器

火雞冒充鴨子項目
背景:火雞類,叫聲AAA飛行:BBB 鴨子類叫聲YYY,飛行FFF.調用適配器,使得某只火雞調用適配器接口之后發出YYY叫聲和FFF飛行

適配器模式:將一個類的接口轉換成另一種接口,讓原本接口不兼容的類可以兼容
從用戶的角度看不到被適配者,是解耦的
用戶調用適配器轉化出來的目標接口方法
適配器調用被適配者的相關接口方法

類適配器:通過多重繼承目標接口和被適配者類方式實現適配
目標
↖
適配器
↙
被適配者
多重繼承,其中繼承的目標接口部分達到適配目的,而繼承被適配者類的部分達到通過調用被適配者類里的方法實現目標接口的功能

對象適配器和類適配器使用了不同的方法實現適配,對象適配器使用組合,類適配器使用繼承

適配器模式案例

低版本java枚舉器與高版本java迭代器適配案例

外觀模式08

家庭影院項目:
如下案例,現在要看電影:步驟為,打開爆米花機->打開投影儀->放下屏幕->放好CD->拿爆米花->關閉爆米花機…
對象與對象之間沒有關聯,但必須同步方可進行事務
如果每一個設備都有各自的按鈕,操作過程將極其繁瑣
為此,引出外觀模式:提供一個統一的接口,來訪問子系統中一群功能相關接口
其定義了一個高層接口,讓子系統更容易使用

與命令模式的區別:側重點不一樣:命令模式,將命令封裝成對象,外觀模式,將子系統功能暴露成為一個接口

外觀模式案例

最少知識原則:盡量減少對象之間的交互,只留幾個關系密切的對象,項目設計中不要讓太多的類耦合在一起
如何遵循:1.對象方法調用范圍,調用自己,作為參數傳進來的對象,此方法創建合實例化的對象,對象的組件但方法返回值例外
最少知識原則Demo

模板模式09

咖啡和泡茶算法:
模板模式:封裝了一個算法步驟,并允許子類為一個或多個步驟方法提供實現
模板模式可以使子類在不改變算法結構的情況下,重新定義算法中的某些步驟
鉤子函數:超類里面定義,子類重寫,若不重寫,則調用鉤子函數,若重寫,調用子類重寫的函數,實現各自功能
抽取完全相同的功能到超類案例
部分子類實現不同的功能案例
通用模板模式案例

好萊塢原則:別調用我們,我們會調用你. 高層無需知道調用底層細節,解耦
擴展性能和維護性能提高

與策略模式的差異:模板封裝步驟,策略模式針對行為等功能進行組合,如鴨子會飛,會叫,會用一個接口對其進行組合.而模板模式:會叫之后再會飛,抽象方法,子類進行實現

迭代器模式10

餐廳菜單合并項目:有兩個餐廳,蛋糕餐廳使用ArrayList維護菜單,中餐廳使用數組維護菜單,現兩個餐廳需要合并為一個餐廳,菜單如何維護?

傳統方案:每個餐廳自己的菜單,暴露出來給外部使用
存在問題:
1.擴展性能差,未來業務擴大,新增一個餐廳合并,該餐廳使用Hash表維護菜單,則必須新增類,暴露該hash菜單
2.耦合度增加:案例中女招待類打印菜單方法使用了暴露的菜單,所以該方法必須修改

詳:
傳統模式案例

迭代器模式:提供一種方法順序訪問一個聚合對象中的各個對象
1.使用迭代器模式,餐廳的增加不影響Waitress類的修改,解耦
2.餐廳未來修改菜單個數,僅需三方服務商修改其內部源碼,直接調用迭代器接口即可,維護性強
迭代器模式案例

java內置迭代器:數組沒有迭代器,自行實現.ArrayList有自己的迭代器,直接使用
現有一使用hash表管理菜單的咖啡館合并入兩家餐館,使用java內置迭代器實現以上項目,詳:
java內置迭代器

單一責任原則:一個類應該只有一個引起變化的原因

組合模式11

餐館增加新需求:給菜單某一項添加子菜單
組合模式:將對象聚合成樹形結構來表現"整體/部分"的層次結構
組合模式能讓客戶以一致的方式來處理個別對象(菜單項)以及對象組合(子菜單),忽略對象組合與>個體對象之間的差別

類結構如下:(最右邊是超類) Waitress <Abstract>1--CakeHouseMenu MenuComponent1--DinerMenu ---------------2--Item operation()2--Item print()2--SubMenu remove()3--Item3--Item3--Item1--CafeMenu2--Item2--Item2--Item

總結:餐廳合并之后,菜單含子菜單,總體菜單項如何進行遍歷??
1.數據結構不一樣如何放一起?
2.樹形節點結構進行統一遍歷
3.菜單,子菜單,菜單項目全部繼承一個超類,即組合模式,整體和局部區別通過超類抹去,解耦,屏蔽內部實現
4.遍歷:使用組合迭代器,巧妙利用堆棧遍歷,獲取菜單的同時又獲取其迭代器,深層遍歷
具體案例如下:

組合模式案例

狀態模式12

項目:智能糖果機,用Java軟件控制糖果機:待機,投入一元硬幣,轉動把手,滑落一顆糖果,
待機(根據機器內糖果庫存情況,是否提示售罄)
糖果機根據狀態的不同,行為結果就不同(如,沒有塞入硬幣轉動把手不掉糖果一種結果和塞入硬幣轉動把手掉出糖果一種結果)

傳統設計方案:一個狀態對應一個動作,采用switch case 強行進行功能實現
則,如果公司增加新需求,加入游戲元素:有10%的概率可以拿到2粒糖果
1.增加一個新狀態贏家狀態,每一個動作的所有switch均要修改,修改開放,耦合大,維護難
2.基于接口開發,不應基于功能開發
傳統模式案例

對于新需求,引入狀態模式,如下:

糖果機項目,狀態和動作之間的關系可以形成如下表格

insertCoin returnCoin turnCrank dispense OnReadyStateHasCoinSoldStateSoldOutStateWinnerState(新增需求,贏家狀態)

面向接口進行開發,所有狀態抽象成一個狀態接口
類結構如下

interface State <interface>1--WinnerState State1--OnReadyState insertCoin()1--HasCoin returnCoin()1--SoldOutState trunCrank()1--SoldState dispense()

狀態模式:根據內部狀態的變化,改變對象的行為,看起來似乎修改了類

狀態模式案例
策略模式一般情況下可以作為狀態模式的基礎,模板模式:部分拼接形成一個整體,狀態模式:每一個狀態都是整體

代理模式13

糖果機監控項目:你是公司上市老板:需要知道各個地方的糖果機運行情況,監控運行
首先,本地糖果機監控,只需要設計一個監控類,類里面放糖果機集合,實現監控情況即可,具體案例如下:
本地監控糖果機案例

好,現公司壯大,糖果賣得火爆,為進行市場分析,需要進行遠程監控糖果機,如何實現?
由此引入代理監控方案–遠程代理:遠程對象(如其他地方糖果機)的本地代表(該糖果機的代表對象),通過它可以讓遠程對象當本地對象來調用
遠程代理通過網絡和真正的遠程對象溝通信息:

Monitor <-> Agent ------------>Machine Monitor訪問Agent,Agent網絡訪問Machine,將結果返回給Monitor,相當于Monitor通過Agent代理,訪問了Machine Java RMI實現遠程代理:Monitor <-> RMI STUB ------------> RMI SKELET <-> Machine

代理模式原理:為一個對象提供一個替身,控制對這個對象的訪問

Java RMI:計算機之間通過網絡實現對象調用的一種通訊機制
該機制可以讓一臺計算機上的對象可以調用另外一臺計算機上的對象來獲取遠程數據

Java RMI 案例如下:

RMIHelloWord服務端
RMIHelloWord客戶端

糖果機項目RMI服務端
糖果機項目RMI客戶端

#####幾種常見代理模式
虛擬代理:虛擬代理為創建開銷大的對象提供代理服務,真正的對象在創建前和創建中時,由虛擬代理扮演替身,如:瀏覽網頁在線圖片加載
動態代理:運行時動態的創建代理類對象,并將方法調用轉發到指定類
保護代理:看一個找對象項目,個人信息,興趣愛好,打分,只可以訪問部分等

使用 Proxy 類進行代理模式之保護代理設計:鏈接如下
權限設置保護代理案例

與裝飾者模式的區別:裝飾者模式,裝飾之后會添加新功能;而代理模式是對目標對象訪問的控制和管理

復合模式14

復合模式能解決一般性或一系列問題

復雜鴨子項目:
多種鴨子,不同鴨子叫聲,飛行,游泳方式不同–策略模式
鵝,需要加入幾只普通的鵝–適配器模式(用鴨子模擬鵝)
要統計鴨子叫聲的次數–裝飾者模式(動態的過程中增加新功能)
統一產生鴨子–工廠模式
管理一群鴨子–組合模式(迭代器)
追蹤某個鴨子的行為–觀察者模式(注冊,反注冊,通知)

MVC:模式與模式進行組合
MVC:Model,View,Controller
MVC解決什么類型的項目需求?
為什么采用MVC結構?
–結構復雜度降低,耦合度降低,不同部分獨立升級

Model:程序主體,代表業務數據和業務邏輯
View:是與用戶交互的界面,顯示數據,接收輸入但不參與實際業務邏輯
Controller:接收用戶輸入,并解析反饋給Model

MVC里的模式:
Model與View和Controller是觀察者模式
View以組合模式管理控件(各種歌曲列表,彈窗等)
View與Controller是策略模式關系,Controller提供策略

以上很拗口,很難理解,以下作具體分析:

分析一個播放器軟件 Model 播放器內部業務__Songs //屬性,歌曲信息列表__State //屬性,狀態(按鈕狀態,播放狀態,歌曲狀態等)--start() //播放--pause() //暫停--stop() //停止--next() //下一首--previous() //上一首--getInfo() //獲取歌曲信息View用戶界面顯示屏 按鈕1,按鈕2,按鈕3,按鈕4你好:這是一個Mp4圖片,請自行想象Controller 策略,行為集,給按鈕增加功能--Button1() --Button2()--Button3()--Button4()模擬:用戶按下了按鈕3,想要切換下一首歌1.通過Controller解析出來該按鈕的功能為切換下一首歌曲2.調用業務邏輯,Model.next()方法被調用,采用觀察者模式通知View,信息變了,View采取相應措施3.歌曲播放完畢,Model觀察者通知View歌曲結束,View相應進行響應,比如彈出一個窗口,歌曲播放完畢或者自動播放下一首歌等4.3這個也可以讓Model通知Controller,具體業務具體分析

Android App就是一個很典型的例子–>
生命周期–模板模式
整體上是MVC
電池電量,觀察者
列表,模板

橋接模式15

橋接目的,分離抽象與實現,使抽象和實現可以獨立變化
系統多維度角度分類,而每一種分類又有可能變化,考慮使用橋接模式

遙控器項目:索尼公司遙控器,廠家提供接口,遙控器調用接口實現遙控各種家電
極簡設計方案:類圖如下:

<interface Control>--On()--Off()--setChannel() //設置頻道--setVolume() //設置音量SonyControl implements Control 實現各自方法--On()--Off()--setChannel()--setVolume() LGControl implements Control 實現各自方法--On()--Off()--setChannel()--setVolume()現有一TvControl想對Sony和LG進行控制,則有SonyTvControl和LGTvControl兩個類

極簡設計方案

該方案存在問題:新需求帶來的設計問題,電視機廠家,新功能的遙控器出來,則新遙控器重新繼承每一個類,類爆炸

橋接模式:將實現與抽象放在兩個不同的類層次重,使兩個層次可以獨立改變
類圖如下:

<abstract> TvControlabs1__Control mControl __代表屬性1--Onoff() -- 代表方法1--nextChannel()1--preChannel()-->2\\TvControl \\代表類 -->代表子類,不屬于同一個文件3--Onoff()3--nextChannel()3--preChannel()-->2\\newTvControl 3--Onoff()3--nextChannel()3--preChannel()3--setChannel()3--Back()mControl∈ 屬于<interface> Control1--On()1--Off()1--setChannel()1--setVolume()-->1\\SonyControl -->代表子類,但不屬于同一個文件2--On()2--Off()2--setChannel()2--setVolume()-->1\\LGControl-->1\\SharpControl

橋接模式案例

生成器模式16

生成器模式:

將復雜對象創建過程封裝
隱藏類的內部結構
允許對象通過幾個步驟創建,并且可以改變工程(工廠模式只有一個步驟)

度假計劃項目:有3天度假計劃,4天度假計劃(每個計劃都是不同對象),如何生成?使用生成器模式:
生成器模式:封裝一個復雜對象構造過程,并允許按步驟構造
具體案例:生成器模式案例

省略抽象生成器類
省略指導者類

與抽象工廠的差異:主要用于創建復雜,大的對象

責任鏈模式17

購買請求決策項目:決策因素:價格
決策級別:組長,部長,副總,總裁
考慮擴展性
如果多個對象都有機會處理請求,責任鏈可使請求的發送者和接受者解耦,請求沿著責任鏈傳遞,直到有一個對象處理了它為止.
該模式簡化了對象,因為無須知道鏈結構
該模式可以動態增加或刪減處理請求的鏈結構
該模式請求從鏈開頭進行遍歷,對性能有一定損耗
該模式并不一定保證請求被處理

項目類圖如下:

PurchaseRequest->A類(請求沒處理,拋!)->B類(請求沒處理,拋!)->C類(請求沒處理,拋!)->D類(請求被處理)

責任鏈模式案例
適用于:有多個對象可以處理一個請求,不明確接收者情況

與狀態模式的差異:責任鏈,注重請求的傳遞,狀態模式,注重對象狀態的轉換

蠅量模式18

景觀設計軟件項目:
樹:XY坐標,樹的大小,外觀,需要很多樹;1000W棵樹,需要對象Tree 1000W 個,小對象大量級的問題解決

傳統方案設計:傳統模式

分析:

Tree1__xCoord1__yCoord1__age1--display() 1000W個Tree對象實在太多,影響性能,該如何做?引入蠅量模式TreeManager1__xArray1__yArray1__AgeArray1--displayTrees()Tree1--display()

蠅量模式案例1

蠅量模式:通過共享的方式高效地支持大量細粒度的對象,適用于大量細粒度對象(上千萬),且這些對象的外部狀態不多
優缺點分析:
優點:
–減少運行時對象實例個數,節省創建開銷和內存
–許多虛擬對象狀態集中管理
缺點:
–系統設計更加復雜
–專門維護對象外部狀態

項目有新需求:增加一些草 類圖如下:

PlantFactory1--getPlant() (PlantManager、Plant類通過該方法顯示具體結果)PlantManager1__xArray1__yArray1__AgeArray1__typeArray1--displayTrees() -> Plant.display()<abstract> Plant1--display()-->1\\Grass2--display()-->1\\Tree2--display()

如何才能實現內存最佳化利用??
引入草對象按蠅量模式設計案例2

解釋器模式19

大數據統計項目:按照計算模型對現有數據統計,分析,預測,計算模型需要運行期編輯,如何設計??寫函數,寫sql?
最好能有一個通用方案,各部門都能通用,維護也方便,擴展也方便,引入解釋器模式:
解釋器模式:計算模型按正常算式方式書寫,解釋器處理語法邏輯;定義一個語法,定義一個解釋器,該解釋器處理該語法句子

計算模式里有兩類符號:數據和計算符(±*/語法規則,優先級等)
逆波蘭算法分析算式語法
用解釋器模式處理數據

優點:
–容易修改,修改語法規則只要修改相應非終結符即可
–擴展方便,擴展語法,增加非終結符類即可
缺點:
–復雜語法,類結構巨復雜,不便管理和維護,盡量不要在重要的模塊中使用
–采用遞歸方式,效率會受影響

可以僅作了解:實際系統開發中使用的非常少
使用場合:數據分析工具,報表設計工具,科學計算工具

原理類圖如下:將某些復雜問題,表達為某種語法規則,然后構建解釋器解釋處理這類句子

用戶Client發出一個算式Context,定義解釋器: AbstractExpression1--Interpret(Context)-->1\\TerminalExpression 子類2--Interpret(Context)-->1\\NoterminalExpression 子類2--Interpret(Context)

回到大數據統計項目,該項目采用解釋器模式進行:類圖如下

<abstract> AbstractExpresstion1--Interpret()-->1--VarExpresstion 變量表達式子類2--Interpret()-->1--SymbolExpresstion 符號表達式子類2--Interpret()-->2--AddExpresstion +3--Interpret()-->2--SubExpresstion -3--Interpret()-->2--MutilExpresstion *3--Interpret()-->2--DivExpresstion /3--Interpret()

解釋器模式案例

中介者模式20

中介者模式,用一個中介對象來封裝一系列的對象交互
中介者使各對象不需要顯式地相互引用,從而使其耦合松散,而且可以獨立地改變它們之間的交互

優點:

–彼此解耦對象,增加對象復用
–控制邏輯集中,簡化系統維護
–對象之間傳遞消息變得簡單而且大幅減少
–提高系統靈活,易于擴展和維護

缺點:

–中介是中心,出現問題則會影響整個系統
–中介者本身對象可能會變得過于復雜源于設計不當

智慧房屋項目:公司專業生產各種房子,房子里有智慧鬧鐘,咖啡機,電視機,窗簾等,實現以下需求
某一時刻,鬧鐘響起,咖啡機自動泡咖啡,同時自動打開電視機,等待咖啡機泡咖啡結束窗簾自動落下,房間燈自動亮起…
傳統設計邏輯:Alarm—1號,TV—2號,CoffeeMachine—3號,Curtains—4號
1給2,3發消息,3給2,4發消息…
對象之間耦合性過強,擴展復用性能差,維護難,不好調試

中介者模式:引入一個中介,Mediator,對象之間省去互相溝通,各對象僅與中介溝通,由中介對結果進行反饋
邏輯:1–中介,2–中介,3–中介,4–中介,中介–1,2,3,4

中介者模式案例

中介者模式與觀察者模式:觀察者模式廣播,中介者定向

適用場合:一組對象之間通信方式比較復雜,導致相互依賴,結構混亂;一個對象引用許多其他對象并直接與這些對象通信,導致難以復用該對象

備忘錄模式21

備忘錄模式:在不破壞封裝的前提下,存儲關鍵對象的重要狀態,從而可以把對象還原到存儲的那個狀態
游戲項目:游戲進度狀態保存問題.對象狀態,場景狀態,大型項目,每個人開發自己的保存功能,這個效率將十分低
引入備忘錄模式:統一功能,每一個人開發的保存功能用一個類進行管理,設計MemetoIF接口,別人開發的細節自己將看不到,保證信息安全

優點:

–狀態存儲在外面,不和關鍵對象混一起,可以幫助維護內聚
–提供容易實現的恢復能力
–保持關鍵對象的數據封裝

缺點:

–資源消耗上面備忘錄對象會很昂貴
–存儲和還原比較耗時

場合:必須保存一個對象在某一個時刻的整體或部分狀態,在對象以外的地方進行恢復

備忘錄模式案例

原型模式22

電子賬單項目:銀行的電子賬單,廣告信,特點,量大,時間要求緊
傳統設計模式案例
問題來了:500萬用戶發送郵件,一封郵件0.1s發出,需要50Ws…6天!

那么解決方案:SendMail多線程并發進行,需要在每一封郵件發送前新創建對象,每次new,內存資源浪費
引入原型模式:一個對象,通過內存復制創建新一模一樣對象,該對象指向其他內存區域,無須知道相應類的信息
優點:

–使用原型模式創建對象比直接new一個對象更有效
–隱藏制造新實例復雜性
–重復創建相似對象時可以考慮使用

缺點

–深層復制比較復雜
–每一個類必須配備一個克隆方法

注意事項:

1.使用原型模式復制對象不會調用類的構造方法!!!所以單例模式與原型模式是沖突的
2.final 對象由于不能改動(其內存空間固定),故采用原型模式的類無法使用final聲明的對象
3.Object類的clone方法只會拷貝對象中的基本數據類型,對于數組,容器,引用對象等都不會拷貝,這就是淺拷貝
4.實現深拷貝必須將原型模式中的數組,容器對象,引用對象等另外拷貝

原型模式案例深拷貝
適用場合:

1.復制對象結構和數據
2.希望對目標對象的修改不影響既有的原型對象
3.創建對象成本較大的情況下

訪問者模式23

雇員管理系統項目:Employee,需要添加一些新的操作功能,具體案例如下:
傳統模式案例 違背開閉原則

訪問者模式:對于一群對象,在不改變數據結構的前提下,增加作用于這些結構元素新的功能,適用于數據結構相對穩定,
數據結構和作用于其上的操作解耦,使得操作集合可以相對自由地演化

優點:

1.一個訪問者一個功能,符合單一職責原則
2.擴展性良好
3.有益于系統的管理和維護

缺點:

1.增加新的元素類變得很困難,修改算法
2.破壞封裝性

訪問者模式案例

注意事項:

1.系統有比較穩定的數據結構
2.與迭代器的關系:迭代器提供訪問者注入的一種方式,訪問者對對象進行處理

適用場合:數據結構比較穩定,需求又經常變化,那么訪問者模式比較適合

寫在最后:

模式:在某些場景下,針對某類問題的某種通用解決方案,其中,場景是項目環境,問題是約束條件,項目目標;解決方案:通用可以復用的設計,解決約束達到目標 (實際經驗的總結) 設計模式的三個分類--創建型模式:對象實例化的模式,解耦了對象的實例化過程--結構型模式:把類或對象結合一起形成更大的結構--行為型模式:類和對象如何交互,及劃分責任和算法

簡單工廠:一個工廠類根據傳入的參量決定創建出哪一種產品類的實例
工廠方法:定義一個創建對象的接口,讓子類決定實例化哪一個類
抽象工廠:創建相關或依賴對象的家族,而無需明確指定具體類
單例模式:類只有一個實例,提供一個全局訪問點
生成器模式:封裝一個復雜對象的構建過程,可以按步驟構造
原型模式:通過復制現有的實例來創建新的實例
適配器模式:將一個類的方法接口轉換成客戶希望的另外一個接口
組合模式:將對象組合成樹形結構以表示"部分-整體"的層次結構
裝飾模式:動態地給對象添加新的功能
代理模式:為其他對象提供一個代理以控制對這個對象的訪問
蠅量模式:通過共享技術有效地支持大量細粒度的對象
外觀模式:提供統一的方法來訪問子系統的一群接口
橋接模式:將抽象部分與它的實現部分分離,使它們都可以獨立地變化
模板模式:定義一個算法結構,而將一些步驟延遲到子類中實現
解釋器模式:給定一個語言,定義它的文法的一種表示,并定義一個解釋器
策略模式:定義一系列的算法,把它們封裝起來,并且使它們可相互替換
狀態模式:允許一個對象在其內部狀態改變時改變它的行為
觀測者模式:對象間的一對多的依賴關系
備忘錄模式:在不破壞封裝性的前提下,保存對象的內部狀態
中介者模式:用一個中介對象來封裝一系列的對象交互
命令模式:將命令請求封裝為一個對象,使得可用不同的請求來進行參數化
訪問者模式:在不改變數據結構的前提下,增加作用于一組對象元素新的功能
責任鏈:請求發送者和接收者之間解耦,使得多個對象都有機會處理這個請求
迭代器:一種遍歷訪問聚合對象中各個元素的方法,不暴露該對象的內部結構

對象設計的六大原則:
組合復用原則:多用組合,少用繼承,找到變化部分,抽象,封裝變化(has A 與 is A).鴨子項目01

依賴倒置原則:

依賴:成員變量,方法參數,返回值,依賴于抽象,不要依賴于具體
高層模塊不應該依賴低層,且都應該依賴其抽象
具體應該依賴抽象,抽象不應該依賴具體
針對接口編程,不要針對實現編程
項目架構:以抽象為基礎搭建

開閉原則:對擴展開放,對修改關閉,通過擴展已有軟件系統,提供新功能,對修改的關閉,保證穩定性和延續性

里氏替換原則:

引用基類的地方必須能透明地使用其子類對象
子類擴展父類功能,不能破壞父類原有的功能
設計繼承,子類可以實現父類的抽象方法,但不能覆蓋父類的非抽象方法
子類重載父類方法,方法的形參要比父類方法的參數更寬松
子類實現父類抽象方法,方法的返回值要比父類更嚴格

迪米特法則:

一個對象應該與其他對象保持最少了解盡量降低類與類之間的耦合

接口隔離原則:一個類對另一個類的依賴應該建立在最小的接口上

單一職責原則:實際工作中很難達到,即一個類只負責一項職責

用模式來思考:
保持簡單:

盡可能用最簡單的方式解決問題

設計模式非萬能:

模式是通用問題的經驗總結
考慮它對其他部分影響
不需要預留任何彈性時,刪除掉模式

何時需要模式:

設計中會變化的部分,通常就是需要考慮模式的地方
重構時,帶進模式

重構的時間就是模式的時間:

利用模式來重構

總結

以上是生活随笔為你收集整理的java设计模式:23种设计模式及其源代码演示实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。