節前把3個(gè)設計模式的學(xué)習心得分享了一下，分別是適配器模式，裝飾模式，代理模式。
但是似乎越寫(xiě)越有些迷糊，這三種模式都有著(zhù)一些大同小異的地方，總是有些搞不清。
今天再重新學(xué)習下，把學(xué)習心得分享給大家一下。這次是結合的我工作中的實(shí)際項目。
設計模式，其實(shí)是一種解決方法，JAVA作為一種面向對象的語(yǔ)言，對于所有的設計模式在實(shí)現上，總是少不了對接口的實(shí)現，對抽象類(lèi)的繼承，有時(shí)候似乎是為了去實(shí)現接口而去寫(xiě)接口，所以在這三種模式的說(shuō)明代碼中，我們都定義了接口這些東西，所以才有了現在的混淆。
先不厭其煩的介紹下這三種的設計模式的概念吧。
適配器模式，一個(gè)適配允許通常因為接口不兼容而不能在一起工作的類(lèi)工作在一起，做法是將類(lèi)自己的接口包裹在一個(gè)已存在的類(lèi)中。
裝飾器模式，原有的不能滿(mǎn)足現有的需求，對原有的進(jìn)行增強。
代理模式，同一個(gè)類(lèi)而去調用另一個(gè)類(lèi)的方法，不對這個(gè)方法進(jìn)行直接操作。
適配器的特點(diǎn)在于兼容，從代碼上的特點(diǎn)來(lái)說(shuō)，適配類(lèi)與原有的類(lèi)具有相同的接口，并且持有新的目標對象。
就如同一個(gè)三孔轉2孔的適配器一樣，他有三孔的插頭，可以插到三孔插座里，又有兩孔的插座可以被2孔插頭插入。
適配器模式是在于對原有3孔的改造。
在使用適配器模式的時(shí)候，我們必須同時(shí)持有原對象，適配對象，目標對象。。。。
裝飾器模式特點(diǎn)在于增強，他的特點(diǎn)是被裝飾類(lèi)和所有的裝飾類(lèi)必須實(shí)現同一個(gè)接口，而且必須持有被裝飾的對象，可以無(wú)限裝飾。
代理模式的特點(diǎn)在于隔離，隔離調用類(lèi)和被調用類(lèi)的關(guān)系，通過(guò)一個(gè)代理類(lèi)去調用。
總的來(lái)說(shuō)就是如下三句話(huà)：
1 適配器模式是將一個(gè)類(lèi)(a)通過(guò)某種方式轉換成另一個(gè)類(lèi)(b).
2 裝飾模式是在一個(gè)原有類(lèi)(a)的基礎之上增加了某些新的功能變成另一個(gè)類(lèi)(b).
3 代理模式是將一個(gè)類(lèi)(a)轉換成具體的操作類(lèi)(b).
又是羅里吧嗦一大段話(huà)，然后我們開(kāi)心的來(lái)到了舉例時(shí)間，這次舉的是工作中實(shí)際的例子。
先簡(jiǎn)單介紹一下，公司有一個(gè)ORDER系統，專(zhuān)門(mén)用于提供訂單管理的接口，提供給O2O商城，WAP商城，手機類(lèi)APP，微信等客戶(hù)端調用。
ORDER系統在上線(xiàn)之時(shí)，已經(jīng)包含了非常完整的數據操作。
現手機類(lèi)APP需要升級，老的接口可能不能滿(mǎn)足需求，如原O2O訂單提貨延長(cháng)有效期接口需要提供截至時(shí)間和訂單號，新APP可能不提供截至時(shí)間，只需要 提供訂單號即可延長(cháng)時(shí)間。
而老的接口又不能修改，因為老的order接口是針對所有平臺的，那么必須將新接口要求與原接口進(jìn)行適配。。。
解決方案如下：新增AppAdepter類(lèi)，用來(lái)適配老的接口，同時(shí)開(kāi)發(fā)給新的接口。。。。
先給出原接口和實(shí)現類(lèi)
原接口：
實(shí)現類(lèi)：
在這套代碼中，對于客戶(hù)端來(lái)說(shuō)需要傳入orderId 和 有效期date 和客戶(hù)端名字才能延長(cháng)。。。
Main方法：
而對于新的接口，客戶(hù)端則不必去傳入date 參數
main方法：
運行結果：
然后在新的方法里，進(jìn)行適配操作。
而這里所謂的適配就是兼容老接口和兼容新接口。
兼容老接口非常簡(jiǎn)單，就是直接調用老的方法即可。
而兼容新接口就是你所要去做的業(yè)務(wù)邏輯。。。
比如我這里做了比較簡(jiǎn)單的操作，app類(lèi)的統一傳入“9999-12-31”，這些都是根據具體的項目需求去實(shí)現你的業(yè)務(wù)代碼。
看到這，很多人會(huì )覺(jué)得 這樣的代碼是不是很常見(jiàn)。。。。
我自己都特意去翻了一下我之前的代碼，很多類(lèi)似的寫(xiě)法。。。
其實(shí)設計模式很多時(shí)候都融入到我們的代碼中，只是我們沒(méi)有去理解這種模式，所以就算你自己寫(xiě)出來(lái)了，都不知道這是一種適配器模式。。。
設計模式是一種思想，他沒(méi)有固定的實(shí)現代碼，我大量查閱了很多大神的的適配器模式解釋?zhuān)蠹叶疾患s而同的提到了類(lèi)的適配和對象的適配，代碼中有實(shí)現繼承這樣的寫(xiě)法。當然了，這些大神的寫(xiě)法都是比較標準的。。。
但是仔細再回看下GOF的適配器模式解釋。
只需要將原接口轉化為客戶(hù)希望的另一個(gè)接口，就是適配器模式！
轉化無(wú)非就是1.繼承原類(lèi)或者實(shí)現原接口 2.持有原接口的對象
再實(shí)現目標接口。。。。
那么第一種就是類(lèi)的適配，第二種就是對象的適配！僅此而已。。。。
那么再回頭來(lái)說(shuō)代理模式，在代碼上，和適配器模式有著(zhù)相似的地方！
再比如，現在我們公司的系統又要進(jìn)行升級，我們原先的接口沒(méi)有加入安全機制，導致了任何人都可以隨意調用這個(gè)接口，現在公司需要對這個(gè)接口進(jìn)行改造，只其只能被admin這個(gè)客戶(hù)端調用，其他用戶(hù)一律要輸入賬號密碼才能調用
那么上面原接口和類(lèi)不需要改動(dòng)，我們只需要新增代理器即可。。。
這里就會(huì )顯出代理模式和適配器模式最大的區別，代理模式是與原對象實(shí)現同一個(gè)接口，而適配器類(lèi)則是匹配新接口，說(shuō)白了，實(shí)現一個(gè)新的接口。
代理類(lèi)：
main方法：
這樣，我們不需要修改原先的實(shí)現類(lèi)，用一個(gè)代理類(lèi)來(lái)進(jìn)行過(guò)濾。有些人可能有這樣的疑惑，為什么不直接在原實(shí)現類(lèi)中修改，記住JAVA設計模式的基本原則，對內關(guān)閉修改。
假如你并沒(méi)有對方的類(lèi)，別人只是提供給你這樣一個(gè)可以操作的JAR包你如何去做？把JAR包反編譯，再修改？又假如某些地方可以直接調用原有接口，你如果修改原有的實(shí)現類(lèi)，豈不是對其他的地方也造成了影響？不能修改原有代碼這是基本原則。
最后，就是裝飾器模式，裝飾器模式與相對于上面2種模式更好理解，差別也最大。
假如說(shuō)，現在這個(gè)延長(cháng)訂單，不光可以延長(cháng)訂單提貨有效期，可以延長(cháng)訂單的退貨有效期。
這就是一個(gè)典型的裝飾器，你需要做的是豐富原接口的功能，并且不改動(dòng)原先的接口。
在裝飾器模式中，必須要有被裝飾的類(lèi)和裝飾的類(lèi)。。在這套代碼中，原先SourceOrderApi的對象就是被裝飾的類(lèi)，而新建NewSourceOrderApiImpl 就是裝飾類(lèi)，裝飾類(lèi)必須把被裝飾的對象當作參數傳入。
這就是和代理模式的代碼不同之處，代理模式一定是自身持有這個(gè)對象，不需要從外部傳入。而裝飾模式的一定是從外部傳入，并且可以沒(méi)有順序，按照代碼的實(shí)際需求隨意挑換順序，就如你吃火鍋先放白菜還是先放丸子都可以。
再從使用上來(lái)看，代理模式注重的是隔離限制，讓外部不能訪(fǎng)問(wèn)你實(shí)際的調用對象，比如權限控制，裝飾模式注重的是功能的拓展，在同一個(gè)方法下實(shí)現更多的功能。
啰啰嗦嗦一大篇文章，大概是把這三種模式好好的整理一下，個(gè)人本身也是徹底理解了這三種模式。
現在可以安心的進(jìn)入下一個(gè)環(huán)節學(xué)習了。。。
匆匆拙筆，如有疏漏錯誤，敬請指出
聯(lián)系客服
