建站
咨詢
售后
建站咨詢
新聞中心
引子
設(shè)計模式是很多程序員總結(jié)出來的優(yōu)秀實踐。曾經(jīng)在剛開始寫項目的時候?qū)W習(xí)過設(shè)計模式，在開發(fā)過程中，也主動或者被動的使用過?，F(xiàn)在寫代碼雖說不會特意明確在用哪種設(shè)計模式，但潛移默化的寫出來公認的優(yōu)秀實踐代碼，畢竟看的比較清爽。為什么再看一遍設(shè)計模式，主要有幾個原因：***，很多優(yōu)秀的源碼基本都使用了設(shè)計模式，明確設(shè)計模式能夠更好的看源碼。第二，很多中間件設(shè)計理念也是基于設(shè)計模式的，還有其他的語言，都有自己的設(shè)計優(yōu)秀實踐。對于我來說，設(shè)計模式始于java，不止于java。第三，有了這種規(guī)范，可以更好的和他人溝通，言簡意賅。
設(shè)計模式原則
很多優(yōu)秀的文章和書籍都講的很明白了，我說下自己的體會。 1.單一職責(zé)原則，就是一個類只負責(zé)做一件事情。這樣就可以做到解耦合的效果，讓代碼看起來比較清爽，也體現(xiàn)了java的封裝性。還有個原則叫迪米特法則，就是一個對象對另一個對象有盡量少的了解，說的也是解耦合的事情。 2.里氏替換原則和依賴導(dǎo)致原則，說的是繼承的事情。父類可以做的事情，子類都可以去做，子類可以盡量去依賴父類去做事情;但是反過來，父類不能依賴子類去做一些事情。體現(xiàn)了java的繼承特性。 3.接口隔離原則，接口也應(yīng)該盡可能的隔離開來。其實類寫多了，的確耦合性低，為了讓他們交流起來，用的最多的就是接口，畢竟只需要知道做什么，怎么做，去訪問那個具體的類吧。 4.開閉原則，對修改關(guān)閉，對拓展開放。就是代碼需要有很好的延展性，對原有代碼結(jié)構(gòu)不能破壞。
創(chuàng)建者模式
創(chuàng)建者模式就是為了用優(yōu)雅的方式創(chuàng)建我們使用的類。
1.簡單工廠模式
這個用的比較少，就是有個工廠，告訴你我要什么東西，你造好了給我就行。比如說：
2.工廠模式
這個其實和簡單工廠模式差不太多，就是將工廠繼續(xù)拆分，比如說剛剛EasyBallFactory是一個總工廠，我們現(xiàn)在拆分成SoccerFactory和BasketBallFactory分別生產(chǎn)足球和籃球。某個工廠內(nèi)部可以根據(jù)需求生產(chǎn)不同的產(chǎn)品，比如說soccer可以生產(chǎn)不同大小的出來。
3.抽象工廠模式
抽象工廠模式主要設(shè)計產(chǎn)品組的概念，就是某一個工廠生產(chǎn)出配套的一系列產(chǎn)品。例如，在生產(chǎn)足球的同時，SoccerFactory還可以生產(chǎn)與之配套的足球雜志。
4.單例模式
單例模式有很多種形式，優(yōu)秀實踐應(yīng)該是兩重判斷，保證只new出來一個。單例可以說是非常普遍的設(shè)計模式了。單例就是指在服務(wù)容器的生命周期中只能有這么一個。比如說Servlet、Spring中注入的Bean等等都是單例的。
5.建造者模式
將一個復(fù)雜對象分布創(chuàng)建。如果一個超大的類的屬性特別多，我們可以把屬性分門別類，不同屬性組成一個稍微小一點的類，再把好幾個稍微小點的類竄起來。比方說一個電腦，可以分成不同的稍微小點的部分CPU、主板、顯示器。CPU、主板、顯示器分別有更多的組件，不再細分。
SpringBoot實現(xiàn)了0配置，幾乎所有的配置都寫到了java代碼中，大量的配置不得不讓配置類采用建造者模式，這樣層次比較清晰。
6.原型模式
原型模式用的比較少，用于創(chuàng)建重復(fù)對象。需要實現(xiàn)Cloneable 可以選擇重寫clone()方法。clone分為淺克隆和深克隆。淺克隆只是克隆引用，對象還是一個。深克隆是對象也新創(chuàng)建了一個，如下：
結(jié)構(gòu)型模式
上面的設(shè)計模式可以幫助我們非常優(yōu)雅的創(chuàng)建出來對象，下面看幾個對象關(guān)系之間的模型。
7.代理模式
Spring的AOP用的是動態(tài)代理，何為動態(tài)不看了，用過Spring的小伙伴都知道吧。單純看一下最基礎(chǔ)代理模式是什么樣的。代理就是，一個對象輔助另一個對象去做某件事，同時還可以增加一點輔助功能。例如，你買車，的確是你花錢把車買到了，但是你不可能直接去和廠家談吧，你應(yīng)該通過4S店購買，同時4S店幫助你入保險扣稅等操作，最終你才得到了你想要的車。
8.適配器模式
適配器，顧名思義，是讓兩個不兼容的東西可以一起工作。例如插座的電源是220V，手機直接給他220V 50HZ的交流電我相信一般都會直接炸了(除了諾基亞...)手機充電器就進行了適配，將電壓變小，交流電變成直流電。除了這種需要改變屬性的操作(比較好說，不舉例子了)，適配器還用于在接口繼承方面。假設(shè)一個***接口有一大堆方法需要實現(xiàn)類實現(xiàn)，我新寫了個類只是想選擇的實現(xiàn)一兩個接口，那其他的方法我是不是都需要實現(xiàn)一下，即使是空實現(xiàn)(單純實現(xiàn)，不進行任何邏輯操作)，這是我們就需要一個適配器類，空實現(xiàn)那些方法，我的新類只需要繼承這個適配器類就好了，要是想實現(xiàn)某個方法，只需要重寫掉配置類中對應(yīng)的方法就好。這種模式基本都會用到，畢竟誰的代碼還沒個***接口啊。
9.橋接模式
就是用于抽象化和實現(xiàn)化的解耦。又是解耦，貌似設(shè)計模式就是教我們?nèi)绾蝺?yōu)雅的解耦。提高了代碼的拓展性，并且可以實現(xiàn)代碼的動態(tài)切換。 最開始的Ball、Soccer、BasketBall接著用，增加新的類。
10.裝飾模式
一個裝飾類，在原來類的基礎(chǔ)上增加一點功能。是不是和代理模式很像，我甚至可以將整個代碼搬過來照樣可以說的通的。這兩個模式意思上有點差別，代理模式是原對象做不了那件事，必須讓代理對象去做，主導(dǎo)側(cè)重于代理對象，比如說買車。裝飾模式是說，就是讓原對象直接去做這件事，只是功能上增強一點，主導(dǎo)在于原對象。比如說炒菜的時候撒點鹽。
11.外觀模式
又稱門面模式，就是一個門面，一個操作無需讓對象知道其內(nèi)部實現(xiàn)的復(fù)雜度，盡量讓用戶感知到是非常簡單的。這就是為什么我們controller層盡量(或者說一定)少些業(yè)務(wù)邏輯，讓controller層只是起到一個傳參和通用性參數(shù)校驗的功能，剩下的全交給service去做吧。我們還需要在代碼中不斷將“長得”特別長的代碼封裝成一個方法，“讓處處都有好看的外觀”。看一下我們曾寫過的代碼，這里只起到了傳參的作用，究竟這個足球是怎么創(chuàng)建出來的，客戶端不必擔(dān)心。
12.組合模式
組合模式是將存在某種包含關(guān)系的數(shù)據(jù)組織在一起，典型的例子就是樹狀結(jié)構(gòu)。例如菜單功能，一個菜單除了自己該有的屬性，還可能包含子菜單，創(chuàng)建的時候可以使用遞歸的方法。
13.享元模式
享元模式盡可能的讓用戶復(fù)用已經(jīng)有的對象，從而避免造成反復(fù)創(chuàng)建對象的資源浪費。首先就會想到數(shù)據(jù)庫連接池還有String常量池，延伸一下，幾乎所有和緩存有關(guān)的代碼，多少都會用到享元模式。享元模式要求大部分的對象可以外部化。這邊要說兩個概念，享元模式對象的屬性可以分為兩個部分，內(nèi)部狀態(tài)和外部狀態(tài)，內(nèi)部狀態(tài)是指不會隨環(huán)境而改變的值，比如說個人信息，外部狀態(tài)是指隨環(huán)境改變的值，不能進行共享的信息，如某大學(xué)生選修的課程。
行為型模式
創(chuàng)建了對象，對象之間有了結(jié)構(gòu)關(guān)系，就要看下怎么更加優(yōu)雅的相互作用了。
14.策略模式
定義一組算法, 將每個算法都封裝起來, 并且使它們之間可以互換。可以說是一組算法的封裝，根據(jù)客戶端給出的不同要求，進行不同的運算。比如下面這個簡易計算器。
15.觀察者模式
定義了一種一對多的依賴關(guān)系，當(dāng)一個對象(被觀察者)狀態(tài)改變的時候，所有依賴于該對象的觀察者都會被通知，從而進行相關(guān)操作。很多中間件都依賴于觀察者模式，例如RabbitMQ，還有那些事件驅(qū)動模型(好像node就是)。下面舉個例子，被觀察者是監(jiān)考老師，考試時間結(jié)束，通知所有觀察者學(xué)生上交試卷。
16.責(zé)任鏈模式
責(zé)任鏈模式為請求創(chuàng)建一個接收者對象的鏈，對發(fā)送者和接受者進行解耦合。filter鏈就是責(zé)任鏈模式。
17.模板方式模式
一個抽象類公開定義了執(zhí)行它的方法的方式/模板。它的子類可以按需要重寫方法實現(xiàn)，但調(diào)用將以抽象類中定義的方式進行。SpringBoot為用戶封裝了很多繼承代碼，都用到了模板方式，例如那一堆XXXtemplate。
18.狀態(tài)模式
簡單來說，就是一個對象有不同的狀態(tài)，根據(jù)狀態(tài)不同，可能有不同的行為。
19.迭代器模式
提供一個方法，可以順序訪問一個對象內(nèi)部的各個元素，不需要知道內(nèi)部構(gòu)造?，F(xiàn)在基本很少自己實現(xiàn)迭代器了，基本成熟的框架或者強大的JDK都會給出訪問的方法，比如說java中iterator。這樣做主要是進一步封裝對象內(nèi)部的結(jié)構(gòu)，讓行為和結(jié)構(gòu)想耦合。這個不舉例子了，用過iterator這個的小伙伴應(yīng)該都清楚，就是不停的next，去訪問下一個元素。
20.命令模式
命令模式是將請求以命令的形式包裹在對象中，并傳遞給對象，調(diào)用對象尋找到處理該命令的合適的對象，并將該命令傳遞給相應(yīng)的對象，該對象執(zhí)行。簡單點說就是不同請求都封裝成一個對象，不同的請求調(diào)用不同的執(zhí)行者。
21.備忘錄模式
相當(dāng)于做一個快照，在不破壞對象本身結(jié)構(gòu)的情況下，記錄對象的一個狀態(tài)，合適的時候可以恢復(fù)到這種狀態(tài)。數(shù)據(jù)庫做事務(wù)回滾的時候就用了這種方式。這里需要注意的是，對象不與備忘錄本身耦合，而是跟備忘錄管理類耦合(就是List<備忘錄>)，這個好理解，畢竟快照不止一個嘛。
22.訪問者模式
當(dāng)對特定角色進行訪問的時候，需要通過訪問者進行訪問。一個對象不太方便被你直接訪問的時候，你需要將自己的引用交給訪問者，通過訪問者去訪問該對象。比如說，化學(xué)課，想看一個細胞結(jié)構(gòu)，由于肉眼無法直接看到微觀世界的玩意，需要通過顯微鏡間接訪問。
23.中介者模式
降低對象或者說事物之間通訊的復(fù)雜性，降低耦合。比如說分布式系統(tǒng)中，不是需要實時反饋的操作，我們無需直接對接，只需將想做的事告訴中間件，中間件告訴另外一個系統(tǒng)。比如說，訪問(用戶點擊)一條新聞操作，同時需要記錄是誰訪問了什么新聞，同時給新聞瀏覽次數(shù)加1，還要實時更新用戶喜好...總之要更新n個數(shù)據(jù)庫表，甚至還要操作像ES,Mongo等多個中間件數(shù)據(jù)。但是對于用戶來說，我只是做了一個點擊操作，希望得到的結(jié)果就是看條新聞啊，你這么多操作，搞這么慢，用戶體驗很差啊，而且并發(fā)量也很低，那不如做成兩個小系統(tǒng)，A系統(tǒng)，拉取新聞，推送，并組裝一個信息扔給MQ中間件，ok，結(jié)束，用戶看到新聞。然后B系統(tǒng)監(jiān)聽，得到這個消息，進行各種更新，這里，這個中間件就是我們的中介。再比如說，MVC中的控制層就是展示層和模型層的中介。再比如說，下面這個聊天室：
24.解釋器模式
構(gòu)建一種翻譯方式，將某種語言或描述翻譯成我們很好理解的語言或者描述。這里很好理解的意思是看得懂，看的快。本來我也想舉什么編譯器這種高大上的，將底層語言甚至機械語言和我們使用的高級編程語言。后來想了想，其實Map就可以看作一個很好的編譯器，key你可以存放一個非常小的字符串，value理論上你可以存放任何東西，所以代碼就不寫了。
網(wǎng)站名稱：大神詳解，這么詳細的Java設(shè)計模式不收藏可惜了
本文URL：http://www.5511xx.com/article/dhpgoeh.html
