更新時間:2021-10-18 13:31:25 來源:動力節點 瀏覽1373次
大家應該都知道,在Java設計模式中會有很多的設計模式應用場景,這些場景也有優缺點,下面小編就來給大家介紹一下。
也被稱為門面模式。當我們開發Android的時候,無論是做SDK還是封裝API,大多都會用到外觀模式,
它通過一個外觀類使得整個系統的結構只有一個統一的高層接口,這樣能降低用戶的使用成本;
定義:要求一個子系統的外部與內部的通信必須通過一個統一的對象進行。此模式提供一個高層的接口,使得子系統更易于使用;
使用場景:
1.構建一個有層次結構的子系統時,使用外觀模式定義子系統中每層的入口點。如果子系統之間是相互依賴的,則可以讓其通過外觀接口進行通信,減少子系統之間的依賴關系;
2.子系統往往會因為不斷的重構演化而變得越來越復雜,大多數的模式使用時也會產生很多很小的類,這給外部使用它們的用戶程序,帶來了使用上的困難。我們可以用外觀類提供一個簡單的接口,對外隱藏子系統的具體實現并隔離變化;
3.當維護一個遺留的大型系統時,可能這個系統已經非常難以維護和拓展;但是因為它含有重要的功能,所以新的需求必須依賴于它,這時可以使用外觀類,為設計粗糙或者復雜的遺留代碼提供一個簡單的接口,讓新系統和外觀類交互,而外觀類負責與遺留的代碼進行交互;
優點:
1.減少系統的相互依賴,所有的依賴都是對外觀類的依賴,與子系統無關;
2.對用戶隱藏了子系統的具體實現,減少用戶對子系統耦合;這樣即使具體的子系統發生了變化,用戶也不會感知到;
3.堅強了安全性,子系統中的方法如果不在外觀類中開通,就無法訪問到子系統中的方法;
缺點:
不符合開放封閉原則。如果業務出現變更,則可能要直接修改外觀類;
定義:將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示;
使用場景:
1.當創建復雜對象的算法應該獨立于該對象的組成部分以及它們的裝配方式時;
2.相同的方法,不同的執行順序,纏身不同的事件結果時;
3.多個部件或零件都可以被裝配到一個對象中,但是產生的運行結果又不相同時;
4.產品類非常復雜,或者產品類中的調用順序不同而產生了不用的效能;
5.在創建一些復雜的對象時,這些對象的內部組成構件間的建造順序是穩定的,但是對象的內部組成構件面臨著復雜的變化
優點:
1.使用建造者模式可以使客戶端不必知道產品內部組成的細節;
2.具體的建造者類之間是相互的獨立的,容易擴展;
3.由于具體的建造者是獨立的,因此可以對建造過程逐步細化,而不對其他的模塊產生任何影響
缺點:
產生多余的Build對象以及導演類;
動態地給一個對象添加一些額外的職責,就增加功能來說,裝飾模式比生成子類更為靈活;
使用場景:
1.在不影響其他對象的情況下,以動態、透明的方式給單個對象添加職責;
2.需要動態地給一個對象增加功能,這些功能可以動態的撤銷;
3.當不能采用繼承的方式對系統進行擴充或者采用繼承不利于系統擴展和維護時;
優點:
1.通過組合而非繼承的方式,動態地擴展一個對象的功能,在運行時選擇不同的裝飾器,從而實現不同的行為;
2.有效避免了使用繼承的方式擴展對象功能而帶來的靈活性差、子類無線擴張的問題;
3.具體組件類與具體裝飾類可以獨立變化,用戶可以根據需要增加新的具體組件類和具體裝飾類,在使用時在對其進行組合, 原有代碼無須改變,符合“開放封閉原則”;
缺點:
1.因為所有對象均繼承于Speciality,所以如果Speciality內部結構發生改變,則不可避免影響所有子類(裝飾者和被裝飾者)。 如果基類改變,則勢必影響對象的內部;
2.比繼承更加靈活機動的特性,也同時意味著裝飾模式比繼承更加易于出錯,排錯也很困難。對于多次裝飾的象,調試時尋找錯誤可能需要逐級排查,較為繁瑣,所以,只在必要的時候使用裝飾模式;
3.裝飾層數不能過多,否則會影響效率;
享元模式是池技術的重要實現方式,它可以減少應用程序創建的對象,降低程序內存的占用,提高程序的性能;
定義:使用共享對象有效地支持大量細粒度的對象;
使用場景:
1.系統中存在大量的相似對象;
2.需要緩沖池的場景;
定義:簡單工廠模式屬于創建型模式,這是由一個工廠對象決定出哪一種產品類的實例
使用場景:
1.工廠類負責創建的對象比較少
2.客戶只需要傳入工廠類的參數,而無需關心創建對象的邏輯
優點:使用戶根據參數獲得對應類的實例,避免了直接實例化類降低了耦合性
缺點:可實例化的類型在編譯期間已經被確定。如果增加新類型,則需要修改工廠,這違背了開放封閉原則。
簡單工廠需要知道所有要生成的類型,其當子類過多或者子類層次過多時不適合使用。
觀察者模式又被稱為發布-訂閱模式,屬于行為型設計模式的一種,是一個在項目中經常使用的模式,
定義:定義對象間一種一對多的依賴關系,每當一個對象改變狀態時,則所有依賴于它的對象都會到得到通知并且自動更新;
使用場景:
1.關聯行為場景。需要注意的是,關聯行為是可拆分的,而不是“組合”關系;
2.事件多級觸發場景;
3.跨系統的消息交換場景,如消息隊列、事件總線的處理機制;
優點:
1.觀察者與被觀察者之間是抽象耦合,容易擴展;
2.方便建立一套觸發機制;
缺點:
在應用觀察者模式時需要考慮一下開發效率和運行效率的問題。程序中包括一個被觀察者、多個觀察者,開發、調試等內容會比較復雜,而且在java中消息的通知一般是順序執行的,那么一個觀察者卡頓,會影響整體的執行效率,在這種情況下,一般會采用異步方式;
定義:為其他對象提供一種代理以控制對這個對象的訪問;
動態代理:在代碼運行時通過反射來動態地生成代理類的對象,并確定道理來代理誰使用范圍:
使用場景:
1.遠程代理:為一個對象在不同的地址空間提供局部代表,這樣系統可以將Server部分實現隱藏;
2.虛擬代理:使用一個代理對象表示一個十分耗費資源的對對象并在真正需要時才創建;
3.安全代理:用來控制真實對象訪問時的權限。一般用于真實對象有不同的訪問權限時;
4.智能指引:當調用真實的對象時,代理處理另外一些事,比如計算機真實對象的引用計數,當該對象沒有引用時,可以自動釋放它;或者訪問一個實際對象時,檢查是否已經能夠鎖定它,以確保其他對象不能改變它;
優點:
1.真實主題類就是實現實際的業務邏輯,不用關心其他非本職的工作;
2.真實主題類隨時都會發生變化,但是因為它實現了公共的接口,所以代理類可以不做任何修改能夠使用;
當我們寫代碼時總會遇到一種情況,就是我們會有很多的選擇,由此衍生出很多的if...else或者case,如果每個條件語句中包含了一個簡單的邏輯,那還比較容易處理;但如果在一個條件語句中又包含了多個條件語句,就會使得代碼變得臃腫,維護的成本也會加大,這顯然違背了開放封閉原則。
定義:定義一系列的算法,報每一個算法封裝起來,并且使它們相互替換。策略模式使得算法可獨立于使用它的客戶而獨立變化;
使用場景:
1.對客戶隱藏具體策略(算法)的實現細節,彼此完全獨立;
2.針對同一類型問題的多種處理方式,僅僅是具體行為有差別時;
3.在一個類中定義了很多行為,而且這些行為在這個類里的操作以多個條件語句的形式出現; 策略模式將相關的條件分支移入他們各自的Strategy類中,以代替這些條件語句;
優點:
1.使用策略模式可以避免使用多重條件語句。多重條件語句不移維護,而且容易出錯;
2.易于拓展,當需要添加一個策略時,只需要實現接口就可以了
缺點:
1.每一個策略都是一個類,復用性小。如果策略過多,類的數量會增加;
2.上層模塊必須知道有哪些策略,才能夠使用這些策略,這與迪米特原則相違背;
在軟件開發中,有事會遇到類似的情況:某個方法的實現需要多個步驟,其中有些步驟是固定的;而有些步驟并不固定,存在可變性。為了提高代碼的復用性和系統的靈活性,可以使用模板方法來應對這類情況;
定義:定義一個操作中的算法框架,而將一些步驟延遲到子類中,是的子類不改變一個算法的結構即可重新定義算法的某些特定步驟;
使用場景:
1.多個子類有共有的方法,并且邏輯基本相同時;
2.面對重要、復雜的算法,可以把核心算法設計為模板方法,周邊相關細節功能則由各個子類實現;
3.需要通過子類來決定父類算法中的某個步驟是否執行,實現子類對父類的反向控制;
優點:
1.模板方法模式通過把不變的行為搬移到超類,去除了子類中的重復代碼;
2.子類實現算法的某些細節,有助于算法的擴展;
缺點:
每個不同的實現都需要定義一個子類,這會導致類的個數的增加,設計更加抽象;
Java的知識點有很多,如果大家想學習更多相關知識,可以來關注一下動力節點的Java在線學習,里面的內容詳細,適合沒有基礎的朋友學習,相信會對大家有所幫助的。
0基礎 0學費 15天面授
有基礎 直達就業
業余時間 高薪轉行
工作1~3年,加薪神器
工作3~5年,晉升架構
提交申請后,顧問老師會電話與您溝通安排學習