大家應(yīng)該都知道，在Java設(shè)計(jì)模式中會有很多的設(shè)計(jì)模式應(yīng)用場景，這些場景也有優(yōu)缺點(diǎn)，下面小編就來給大家介紹一下。

外觀模式：

也被稱為門面模式。當(dāng)我們開發(fā)Android的時(shí)候，無論是做SDK還是封裝API，大多都會用到外觀模式，

它通過一個(gè)外觀類使得整個(gè)系統(tǒng)的結(jié)構(gòu)只有一個(gè)統(tǒng)一的高層接口，這樣能降低用戶的使用成本;

定義：要求一個(gè)子系統(tǒng)的外部與內(nèi)部的通信必須通過一個(gè)統(tǒng)一的對象進(jìn)行。此模式提供一個(gè)高層的接口，使得子系統(tǒng)更易于使用;

使用場景：

1.構(gòu)建一個(gè)有層次結(jié)構(gòu)的子系統(tǒng)時(shí)，使用外觀模式定義子系統(tǒng)中每層的入口點(diǎn)。如果子系統(tǒng)之間是相互依賴的，則可以讓其通過外觀接口進(jìn)行通信，減少子系統(tǒng)之間的依賴關(guān)系;

2.子系統(tǒng)往往會因?yàn)椴粩嗟闹貥?gòu)演化而變得越來越復(fù)雜，大多數(shù)的模式使用時(shí)也會產(chǎn)生很多很小的類，這給外部使用它們的用戶程序，帶來了使用上的困難。我們可以用外觀類提供一個(gè)簡單的接口，對外隱藏子系統(tǒng)的具體實(shí)現(xiàn)并隔離變化;

3.當(dāng)維護(hù)一個(gè)遺留的大型系統(tǒng)時(shí)，可能這個(gè)系統(tǒng)已經(jīng)非常難以維護(hù)和拓展;但是因?yàn)樗兄匾墓δ?，所以新的需求必須依賴于它，這時(shí)可以使用外觀類，為設(shè)計(jì)粗糙或者復(fù)雜的遺留代碼提供一個(gè)簡單的接口，讓新系統(tǒng)和外觀類交互，而外觀類負(fù)責(zé)與遺留的代碼進(jìn)行交互;

優(yōu)點(diǎn)：

1.減少系統(tǒng)的相互依賴，所有的依賴都是對外觀類的依賴，與子系統(tǒng)無關(guān);

2.對用戶隱藏了子系統(tǒng)的具體實(shí)現(xiàn)，減少用戶對子系統(tǒng)耦合;這樣即使具體的子系統(tǒng)發(fā)生了變化，用戶也不會感知到;

3.堅(jiān)強(qiáng)了安全性，子系統(tǒng)中的方法如果不在外觀類中開通，就無法訪問到子系統(tǒng)中的方法;

缺點(diǎn)：

不符合開放封閉原則。如果業(yè)務(wù)出現(xiàn)變更，則可能要直接修改外觀類;

建造者模式：也被稱為生成器模式;

定義：將一個(gè)復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示;

使用場景：

1.當(dāng)創(chuàng)建復(fù)雜對象的算法應(yīng)該獨(dú)立于該對象的組成部分以及它們的裝配方式時(shí);

2.相同的方法，不同的執(zhí)行順序，纏身不同的事件結(jié)果時(shí);

3.多個(gè)部件或零件都可以被裝配到一個(gè)對象中，但是產(chǎn)生的運(yùn)行結(jié)果又不相同時(shí);

4.產(chǎn)品類非常復(fù)雜，或者產(chǎn)品類中的調(diào)用順序不同而產(chǎn)生了不用的效能;

5.在創(chuàng)建一些復(fù)雜的對象時(shí)，這些對象的內(nèi)部組成構(gòu)件間的建造順序是穩(wěn)定的，但是對象的內(nèi)部組成構(gòu)件面臨著復(fù)雜的變化

優(yōu)點(diǎn)：

1.使用建造者模式可以使客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié);

2.具體的建造者類之間是相互的獨(dú)立的，容易擴(kuò)展;

3.由于具體的建造者是獨(dú)立的，因此可以對建造過程逐步細(xì)化，而不對其他的模塊產(chǎn)生任何影響

缺點(diǎn)：

產(chǎn)生多余的Build對象以及導(dǎo)演類;

裝飾器模式：

動(dòng)態(tài)地給一個(gè)對象添加一些額外的職責(zé)，就增加功能來說，裝飾模式比生成子類更為靈活;

使用場景：

1.在不影響其他對象的情況下，以動(dòng)態(tài)、透明的方式給單個(gè)對象添加職責(zé);

2.需要?jiǎng)討B(tài)地給一個(gè)對象增加功能，這些功能可以動(dòng)態(tài)的撤銷;

3.當(dāng)不能采用繼承的方式對系統(tǒng)進(jìn)行擴(kuò)充或者采用繼承不利于系統(tǒng)擴(kuò)展和維護(hù)時(shí);

優(yōu)點(diǎn)：

1.通過組合而非繼承的方式，動(dòng)態(tài)地?cái)U(kuò)展一個(gè)對象的功能，在運(yùn)行時(shí)選擇不同的裝飾器，從而實(shí)現(xiàn)不同的行為;

2.有效避免了使用繼承的方式擴(kuò)展對象功能而帶來的靈活性差、子類無線擴(kuò)張的問題;

3.具體組件類與具體裝飾類可以獨(dú)立變化，用戶可以根據(jù)需要增加新的具體組件類和具體裝飾類，在使用時(shí)在對其進(jìn)行組合， 原有代碼無須改變，符合“開放封閉原則”;

缺點(diǎn)：

1.因?yàn)樗袑ο缶^承于Speciality，所以如果Speciality內(nèi)部結(jié)構(gòu)發(fā)生改變，則不可避免影響所有子類(裝飾者和被裝飾者)。 如果基類改變，則勢必影響對象的內(nèi)部;

2.比繼承更加靈活機(jī)動(dòng)的特性，也同時(shí)意味著裝飾模式比繼承更加易于出錯(cuò)，排錯(cuò)也很困難。對于多次裝飾的象，調(diào)試時(shí)尋找錯(cuò)誤可能需要逐級排查，較為繁瑣，所以，只在必要的時(shí)候使用裝飾模式;

3.裝飾層數(shù)不能過多，否則會影響效率;

享元模式:

享元模式是池技術(shù)的重要實(shí)現(xiàn)方式，它可以減少應(yīng)用程序創(chuàng)建的對象，降低程序內(nèi)存的占用，提高程序的性能;

定義：使用共享對象有效地支持大量細(xì)粒度的對象;

使用場景：

1.系統(tǒng)中存在大量的相似對象;

2.需要緩沖池的場景;

簡單工廠模式(又叫作靜態(tài)工廠方法模式)

定義：簡單工廠模式屬于創(chuàng)建型模式，這是由一個(gè)工廠對象決定出哪一種產(chǎn)品類的實(shí)例

使用場景：

1.工廠類負(fù)責(zé)創(chuàng)建的對象比較少

2.客戶只需要傳入工廠類的參數(shù)，而無需關(guān)心創(chuàng)建對象的邏輯

優(yōu)點(diǎn)：使用戶根據(jù)參數(shù)獲得對應(yīng)類的實(shí)例，避免了直接實(shí)例化類降低了耦合性

缺點(diǎn)：可實(shí)例化的類型在編譯期間已經(jīng)被確定。如果增加新類型，則需要修改工廠，這違背了開放封閉原則。

簡單工廠需要知道所有要生成的類型，其當(dāng)子類過多或者子類層次過多時(shí)不適合使用。

觀察者模式

觀察者模式又被稱為發(fā)布-訂閱模式，屬于行為型設(shè)計(jì)模式的一種，是一個(gè)在項(xiàng)目中經(jīng)常使用的模式，

定義：定義對象間一種一對多的依賴關(guān)系，每當(dāng)一個(gè)對象改變狀態(tài)時(shí)，則所有依賴于它的對象都會到得到通知并且自動(dòng)更新;

使用場景：

1.關(guān)聯(lián)行為場景。需要注意的是，關(guān)聯(lián)行為是可拆分的，而不是“組合”關(guān)系;

2.事件多級觸發(fā)場景;

3.跨系統(tǒng)的消息交換場景，如消息隊(duì)列、事件總線的處理機(jī)制;

優(yōu)點(diǎn)：

1.觀察者與被觀察者之間是抽象耦合，容易擴(kuò)展;

2.方便建立一套觸發(fā)機(jī)制;

缺點(diǎn)：

在應(yīng)用觀察者模式時(shí)需要考慮一下開發(fā)效率和運(yùn)行效率的問題。程序中包括一個(gè)被觀察者、多個(gè)觀察者，開發(fā)、調(diào)試等內(nèi)容會比較復(fù)雜，而且在java中消息的通知一般是順序執(zhí)行的，那么一個(gè)觀察者卡頓，會影響整體的執(zhí)行效率，在這種情況下，一般會采用異步方式;

代理模式：也被稱為委托模式，它是結(jié)構(gòu)型設(shè)計(jì)模式的一種。

定義：為其他對象提供一種代理以控制對這個(gè)對象的訪問;

動(dòng)態(tài)代理：在代碼運(yùn)行時(shí)通過反射來動(dòng)態(tài)地生成代理類的對象，并確定道理來代理誰使用范圍：

使用場景：

1.遠(yuǎn)程代理：為一個(gè)對象在不同的地址空間提供局部代表，這樣系統(tǒng)可以將Server部分實(shí)現(xiàn)隱藏;

2.虛擬代理：使用一個(gè)代理對象表示一個(gè)十分耗費(fèi)資源的對對象并在真正需要時(shí)才創(chuàng)建;

3.安全代理：用來控制真實(shí)對象訪問時(shí)的權(quán)限。一般用于真實(shí)對象有不同的訪問權(quán)限時(shí);

4.智能指引：當(dāng)調(diào)用真實(shí)的對象時(shí)，代理處理另外一些事，比如計(jì)算機(jī)真實(shí)對象的引用計(jì)數(shù)，當(dāng)該對象沒有引用時(shí)，可以自動(dòng)釋放它;或者訪問一個(gè)實(shí)際對象時(shí)，檢查是否已經(jīng)能夠鎖定它，以確保其他對象不能改變它;

優(yōu)點(diǎn)：

1.真實(shí)主題類就是實(shí)現(xiàn)實(shí)際的業(yè)務(wù)邏輯，不用關(guān)心其他非本職的工作;

2.真實(shí)主題類隨時(shí)都會發(fā)生變化，但是因?yàn)樗鼘?shí)現(xiàn)了公共的接口，所以代理類可以不做任何修改能夠使用;

策略模式

當(dāng)我們寫代碼時(shí)總會遇到一種情況，就是我們會有很多的選擇，由此衍生出很多的if...else或者case，如果每個(gè)條件語句中包含了一個(gè)簡單的邏輯，那還比較容易處理;但如果在一個(gè)條件語句中又包含了多個(gè)條件語句，就會使得代碼變得臃腫，維護(hù)的成本也會加大，這顯然違背了開放封閉原則。

定義：定義一系列的算法，報(bào)每一個(gè)算法封裝起來，并且使它們相互替換。策略模式使得算法可獨(dú)立于使用它的客戶而獨(dú)立變化;

使用場景：

1.對客戶隱藏具體策略(算法)的實(shí)現(xiàn)細(xì)節(jié)，彼此完全獨(dú)立;

2.針對同一類型問題的多種處理方式，僅僅是具體行為有差別時(shí);

3.在一個(gè)類中定義了很多行為，而且這些行為在這個(gè)類里的操作以多個(gè)條件語句的形式出現(xiàn); 策略模式將相關(guān)的條件分支移入他們各自的Strategy類中，以代替這些條件語句;

優(yōu)點(diǎn)：

1.使用策略模式可以避免使用多重條件語句。多重條件語句不移維護(hù)，而且容易出錯(cuò);

2.易于拓展，當(dāng)需要添加一個(gè)策略時(shí)，只需要實(shí)現(xiàn)接口就可以了

缺點(diǎn)：

1.每一個(gè)策略都是一個(gè)類，復(fù)用性小。如果策略過多，類的數(shù)量會增加;

2.上層模塊必須知道有哪些策略，才能夠使用這些策略，這與迪米特原則相違背;

模板方法模式：

在軟件開發(fā)中，有事會遇到類似的情況：某個(gè)方法的實(shí)現(xiàn)需要多個(gè)步驟，其中有些步驟是固定的;而有些步驟并不固定，存在可變性。為了提高代碼的復(fù)用性和系統(tǒng)的靈活性，可以使用模板方法來應(yīng)對這類情況;

定義：定義一個(gè)操作中的算法框架，而將一些步驟延遲到子類中，是的子類不改變一個(gè)算法的結(jié)構(gòu)即可重新定義算法的某些特定步驟;

使用場景：

1.多個(gè)子類有共有的方法，并且邏輯基本相同時(shí);

2.面對重要、復(fù)雜的算法，可以把核心算法設(shè)計(jì)為模板方法，周邊相關(guān)細(xì)節(jié)功能則由各個(gè)子類實(shí)現(xiàn);

3.需要通過子類來決定父類算法中的某個(gè)步驟是否執(zhí)行，實(shí)現(xiàn)子類對父類的反向控制;

優(yōu)點(diǎn)：

1.模板方法模式通過把不變的行為搬移到超類，去除了子類中的重復(fù)代碼;

2.子類實(shí)現(xiàn)算法的某些細(xì)節(jié)，有助于算法的擴(kuò)展;

缺點(diǎn)：

每個(gè)不同的實(shí)現(xiàn)都需要定義一個(gè)子類，這會導(dǎo)致類的個(gè)數(shù)的增加，設(shè)計(jì)更加抽象;

Java的知識點(diǎn)有很多，如果大家想學(xué)習(xí)更多相關(guān)知識，可以來關(guān)注一下動(dòng)力節(jié)點(diǎn)的Java在線學(xué)習(xí)，里面的內(nèi)容詳細(xì)，適合沒有基礎(chǔ)的朋友學(xué)習(xí)，相信會對大家有所幫助的。