摘要:小麗總是會在朋友圈發布自己的各種生活狀態。總結我們從觀察者模式特點入手,通過一個案例,一步一步完善了觀察著的寫法,特點組后介紹了總已有的實現關注我,這里只有干貨同系列文章從未這么明白的設計模式一單例模式
本文原創地址,我的博客:https://jsbintask.cn/2019/04/15/designpattern/observer/(食用效果最佳),轉載請注明出處!前言
觀察者模式定義了對象間的一種一對多依賴關系,當一個對象狀態發生改變時,觀察者們都可以做出相應的更新,使得系統更易于擴展!
代碼地址:https://github.com/jsbintask22/design-pattern-learning
小麗長得很漂亮,"天生麗質難自棄", 是一個不折不扣的"女神"。
小麗身邊有很多”備胎“,他們通過各種方式添加了小麗的微信,“小豪,小吳”都是其中之一。
小麗總是會在朋友圈發布自己的各種生活狀態。
”備胎們“總是及時并且積極地和女神互動!
小麗發現”備胎“小豪不愛互動了,于是刪除了“備胎”小豪的微信。
小豪發現自己看不了女神動態了。最終死心!
小麗認識了新“備胎”小李,于是小李也添加了女神微信。
小麗發布自己的朋友圈動態,小李也開始了互動!
上面這個過程我們可以抽象出來兩個主題,女神小麗,備胎小豪,小吳,小李,我們用代碼模擬這個追女神的過程。
代碼實現 V1.0Beauty代表女神,LittleBoy表示備胎,他們時刻在關注著女神的朋友圈,希望獲得互動,代碼實現如下:
public class App { public static void main(String[] args) throws Exception{ Beauty beauty = new Beauty(); // 成功添加了女神微信 LittleBoy littleBoy = new LittleBoy(beauty); // 開始查看女神朋友圈 littleBoy.start(); // 5s后,女神發布了朋友圈。 Thread.sleep(5000L); beauty.publishWechat(); System.in.read(); } }
運行結果如下:
嗯!似乎很完美! 美中不足的是好像LittleBoy的run方法一直在輪詢查看女神朋友圈,它沒辦法做自己的事情了:
這樣下去很快他就會失去和女神互動的耐心! 所以我們稍微修改下,讓這段代碼看起來更加”智能”。
為了不讓LittleBoy一直輪詢查看女神狀態,我們可以修改為女神主動推送她的狀態給“備胎們”,這樣他們就可以去做其他事情了!
public class App { public static void main(String[] args) throws Exception{ Beauty beauty = new Beauty(); LittleBoy littleBoy = new LittleBoy(); // 添加女神微信 beauty.littleBoy = littleBoy; // 發布動態 beauty.publishWechat(); } }
嗯!這樣一來就智能多了! 女神更新朋友圈后主動推送消息給備胎!備胎不用死守著女神的朋友圈,而是收到消息后自動去查看。所以他們的關系是這樣了:
但是,現在又有一個新問題!這段代碼好像顯得不夠面向對象,不夠專業。
女神如果想要新加一個舔狗,就要動女神的邏輯代碼。
新加了一個備胎之后,不知道如何把自己的動態分享給他(例如上面的active方法,可能“新備胎”沒有)。
備胎突然舔不動了怎么辦了,他不想再收到女神動態了!
既然這樣,我們把這段代碼修改下,讓它變得“靈活”,更加“面向對象”些!
V3.0既然要靈活,面向對象。我們這么處理:將女神抽象為一個接口,并且她要能夠刪除備胎,添加備胎,通知備胎。同時我們將備胎抽象為一個接口,他能夠在收到女神通知后及時做出反應!
Beauty:
LittleBoy:
它們分別有一個實現:BeautyImpl和LittleBoyImpl:
測試代碼:
public class App { public static void main(String[] args) { Beauty beauty = new BeautyImpl(); LittleBoy boy1 = new LittleBoyImpl("小豪"); LittleBoy boy2 = new LittleBoyImpl("小吳"); // 添加兩個備胎 beauty.addLittleBoy(boy1); beauty.addLittleBoy(boy2); // 發布朋友圈 beauty.publishWechat("最美的不是下雨天,是曾和你一起躲過雨的屋檐!"); // 刪除備胎1,并且新添加了備胎3 beauty.removeLittleBoy(boy1); beauty.addLittleBoy(msg -> { System.out.println(" 小李:哎喲,不錯哦!"); }); // 再次發布朋友圈 beauty.publishWechat("哪里有彩虹告訴我。。。"); } }
嗯!通過面向接口編程完美的解決了上面的問題,現在女神這個類已經變得非常靈活了,仔細觀察,我們已經把我們上面的說的案例完全實現!現在它們的關系是這樣的:
觀察者模式這種發布與訂閱的思想使用的非常廣泛,基本各個框架,思想都能看到它的身影,而jdk中也已經抽象了觀察與被觀察者:
java.util.Observer表示觀察者:
java.util.Obserable表示被觀察者(例如上面的女神):
然后美中不足的是,jdk把Observable設計成了一個類,這并不利于擴展! 當然我們仍然可以自己實現接口,就像上面所做的。
我們從觀察者模式特點入手,通過一個案例,一步一步完善了觀察著的寫法,特點!組后介紹了jdk總已有的實現!
關注我,這里只有干貨!
同系列文章:
從未這么明白的設計模式(一):單例模式
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/74101.html
摘要:一般來說,這種單例實現有兩種思路,私有構造器,枚舉。而這種方式又分了飽漢式,餓漢式。通過關鍵字防止指令重排序。什么是單例?為什么要用單例? 一個類被設計出來,就代表它表示具有某種行為(方法),屬性(成員變量),而一般情況下,當我們想使用這個類時,會使用new關鍵字,這時候jvm會幫我們構造一個該類的實例。而我們知道,對于new這個關鍵字以及該實例,相對而言是比較耗費資源的。所以如果我們能夠想...
摘要:我們今天也來做一個萬能遙控器設計模式適配器模式將一個類的接口轉換成客戶希望的另外一個接口。今天要介紹的仍然是創建型設計模式的一種建造者模式。設計模式的理論知識固然重要,但 計算機程序的思維邏輯 (54) - 剖析 Collections - 設計模式 上節我們提到,類 Collections 中大概有兩類功能,第一類是對容器接口對象進行操作,第二類是返回一個容器接口對象,上節我們介紹了...
摘要:其實通過父類的這個方法之后會調用它的方法,這個名字熟悉自定義的童鞋都知道了。 為什么要寫這篇源碼解析呢? 我一直在說RecyclerView是一個值得深入學習,甚至可以說是一門具有藝術性的控件。那到底哪里值得我們花時間去深入學習呢。沒錯了,就是源碼的設計。但是看源碼其實是一件不簡單的事情,就拿RecyclerView的源碼來說,打開源碼一看,往下拉啊拉啊,我擦,怎么還沒到頭,汗.......
閱讀 1163·2021-11-15 18:14
閱讀 3627·2021-11-15 11:37
閱讀 754·2021-09-24 09:47
閱讀 2427·2021-09-04 16:48
閱讀 2182·2019-08-30 15:53
閱讀 2379·2019-08-30 15:53
閱讀 390·2019-08-30 11:20
閱讀 1232·2019-08-29 16:08