[討論] Pub/Sub vs Observer Pattern

[Jasonzheng (jason)]

感謝 pttuser 大
這麼認真回覆我的"觀察者模式"
我只好發一篇討論一下


正文:

我知道有些會說
Pub/Sub 與 Observer 不同

有些說
兩種 pattern 根本不同層面
一個是網路導向架構 一個只是物件導向的實做
一個是 async 一是 sync ..等

如
Stackoverflow
https://goo.gl/qRUQOK


但是很抱歉
Observer Pattern
的確就是 Pub/Sub Pattern

這不是自我感覺良好
講話要有根據的

首先，昨晚回覆過的
GoF 原著就說了
Observer 別名
就是 Publish/Subscribe
http://i.imgur.com/4l7B6P7.jpg

GoF 設計模式 ，相信早已是必讀聖經
他們著作就是這樣寫
你要說他們錯，另起爐灶，我也是佩服

但是，我也不是說 async/sync 的觀點錯誤

在不同時空背景，不同語言... 的狀況下
Pub/Scribe 運用在不同的領域
意義當然不一樣
簡直就像拿明朝的劍，斬清朝的官一般

良葛格也說過
技術名詞紛爭多
https://goo.gl/MkqlMx

學的是模式的原理與精髓
這些名詞理應是拿來溝通
方便吸收理解
不是拿來給您裝逼的

另外，您說我只會死讀書翻譯
那我蠻開心的
起碼我有花時間在這塊
並非口說無憑

我反而懷疑，您是否有實務開發經驗?
實務中，這些模式並沒有限制做法
反而都會變形與結合
從來沒有人說
Observer 只能用 sync 或 async
其根本，的確就是「發佈-訂閱」的概念

最後
以下這些書籍也都是相同論點
不知您是否還認為，只有自己正確呢?

設計模式之禪
http://i.imgur.com/VaawqKz.jpg

GoF原文中譯
http://i.imgur.com/ARCZcdv.jpg

品味Java的21種設計模式
http://i.imgur.com/QfYJWMS.jpg

大話設計模式
http://i.imgur.com/3DG8Udu.jpg

設計模式
http://i.imgur.com/XvvOVUE.jpg

深入淺出設計模式
http://i.imgur.com/5tfrgVj.jpg


謝謝指教

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.72.156.63
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1483578056.A.A2A.html
※ 編輯: Jasonzheng (42.72.156.63), 01/05/2017 09:03:01
噓 pttuser: 去看看aws等大廠怎麼作pub/sub的啦，看看現在實作的產品
→ pttuser: 怎麼區別pub/sub和observer吧
推 Trick: 好痛
推 aws9527: 哈哈哈 好腫
推 femlro: 好多書喔XD
買書月光族...
→ femlro: 推推
噓 pttuser: 再不濟就去參加pycon or jcconf這種entry level型的討論
→ pttuser: 看看現實生活中實作面為何盡量區分兩者的不同
推 srxrrr: 我是不了解這個技術 但p大火氣也太大了吧 人家好心分享
→ srxrrr: 如果覺得有誤 就好好討論 拼命噓做啥...
噓 pttuser: 一天到晚只會糾結名詞，現實實作中早已經把兩者分開談了
推 dreamnook: ww
推 Trick: 糾結名詞的是誰啊
噓 pttuser: 還好痛咧，我是擔心哪天某個新人被要求作pub/sub，結果
→ pttuser: 看你的文章寫出sync observer結果下場就很慘了
→ pttuser: 你的文章有講到async和sync差別？新人光看你文章只會被你
→ pttuser: 誤導就是sync
ok 的確有可能
((雖然我一再強調 Observer 沒有 sync 規範...
我稍晚會在補充進內文
以免誤導他人 謝大大指教^^
→ pttuser: 真是笑話，這種實際面早已區分的作法居然被你混為一談
敝人認為
其實就只是名詞重用
並非混為一談
內文討論的範疇 就是 Observer 無誤
推 jack0204: 發一篇文章來讓大家看看你的觀點阿
→ femlro: 冷靜冷靜，討論不要生氣
噓 pttuser: 叫我寫就寫？你哪根蔥？林北要來gdb了不陪你們練校話
推 wix3000: 看起來跟腦羞有87%像
→ dreamnook: 那我只好放個激醬了 寫不出來只好噓
→ dreamnook: 你要牛肉還是豬肉?
→ robler: 哈哈哈 惱羞成怒囉 講不出東西來就顧左右而言他 裝忙XD
噓 pttuser: 林北是不用上班膩？當我跟你們一樣都是學生嗎
小弟開工中
晚上再補充~
→ robler: 不懂在那邊裝懂 被打臉了就假裝要上班沒空 哈哈
→ dnabossking: 一大早火氣就這麼大，也是不簡單
→ dreamnook: 我也有上班呀 只是不會閒到可以一直噓而已
推 ripple0129: 過度探討名詞解釋是不健康的
沒錯..爭名詞超沒意義阿阿啊
推 loveflames: 如果這麼忙，怎麼有時間一直噓
推 vn509942: 最喜歡看論戰了
→ kightkids: 我偏向支持pttuser. observe pattern 只有1對多.
→ kightkids: 但pub/sub是可以多對多的概念.
→ kightkids: 可以說pub/sub有observe的概念，但反過來說aka就不行。
的確，現今實務中的 pub/sub ，類似把 observer 當實做子集的概念。
但我文中所指的是更高的抽象層次
謝謝討論:)
推 elements: 常有人說 xxx 只是工具，重要的是背後的腦袋
→ elements: 名詞..很重要.. 但知道某些名詞被重用也是你的能力之一
沒錯! 其實就只是名詞重用
→ elements: 事實上詞彙指的常常是一片東西 而不是一個東西
→ elements: 真要挑語病 挑不完的
→ elements: 至於 GoF 的公信力... 我個人是覺得還好.. 也就本書
因為我在探討的
就是該書阿 xd
推 vencil: 糾結名詞又惱羞
→ elements: 我剛畢業的時候也很注重名詞.. 但你發現幾個強者講的不
→ elements: 一樣，就漸漸覺得應該要學習能夠穿過詞彙去懂那個想法
有感，許多名詞提出時，抽象層次高
一有普遍實務做法，就容易被混淆重定義
要爭爭不完..
推 gn01838335: 一直狂噓xdd
→ pttworld: 認為是另一個名字、稱呼，路過。
感謝:)
→ chocopie: http://i.imgur.com/Lz2JJA7.jpg
推 Ekmund: 等等 observer有規定只能一對多？
→ Ekmund: subject完全可以擴展吧
沒錯
噓 sing10407: 連討論都不討論就說打臉別人? 我還以為是覺醒青年版
這不是在討論嘛o.o
推 ug945: 戰技術不錯啊 XD
推 gn01838335: Subjet擴展違背原則啊xdd
→ gn01838335: 戰這個每個人有很多意見xdd
→ gn01838335: 我可以加入戰局嗎
其實我也覺得蠻有趣的 xd

我說一下我的看法
用個比較爛的例子:
「就像資料庫的概念
多對多，其實就是兩個反向一對多」

原著中有提到一個 Observer
是可以觀察多個 Subject 的
一對多僅為單一抽象觀念的兩個層面

→ Ekmund: 可以 我只寫過pub/sub 是真的不懂在求教
原著有說明
當遇見複雜的情形
可以在引入 中介者模式的變化
或再結合 單例模式
Observer Pattern
本身抽象程度高、變形之廣
可想而知@@

推 Sirctal: pttworld幹嘛火氣那麼大 大家都要上班阿...
→ Sirctal: 你可以晚上寫一篇pub/sub 跟 observer的差異吧...
→ dreamnook: 欸 是同一個人嗎XD
應該不是吧 xd
→ Sirctal: 既然你都提出來問題 發表一下不為過吧 能力越大 責任越大
※ 編輯: Jasonzheng (42.72.156.63), 01/05/2017 12:02:42
推 chocopie: 奇怪pttworld只是剛路過啊，你說的是pttuser吧？XD
推 gn01838335: 寫code太久眼睛花了嗎？
推 gotptt: 感覺observer是包含了pub/sub啦  更大的軟體架構
→ gotptt: 就好像pipeline包含data double buffer
推 gn01838335: 樓上正解
求轉載兩位言論 xd
不然好像我很主觀 qq
推 Frozenmouse: 我覺得現代的pub/sub就是observer的變形應用啊XD
我也覺得..
→ gn01838335: 但是要做到很困難
→ gn01838335: 所以才有pub sub誕生
→ gn01838335: 若要乾淨的原則來講本來就是包含pub sub
→ gn01838335: 但做不到啊
→ dreamnook: 我是覺得好像變成在爭執設計上跟應用的差異
真的! 設計跟實務
本來就差很多..
→ dreamnook: 能夠釐清更好 我也不懂為啥Subject增加違反原則XD
推 Sirctal: XD 看錯了 開頭都是ptt
※ 編輯: Jasonzheng (42.72.156.63), 01/05/2017 12:06:01
推 gn01838335: 我們不是學者，做出有意義可維護高的東西可擴充，異
→ gn01838335: 懂的東西就好。比較來到實價不是嗎xdd
→ gn01838335: 我也覺得你的分享很棒啊，但設計模式怎麼用是團隊共
→ gn01838335: 識。解耦，不過份鬆散，可擴充，彈性
推 gn01838335: 原則掌握好大家都是設計大師
→ gn01838335: 說真的我工作那麼多年看過很多家公司很少強調要什麼
→ gn01838335: 模式xddd
推 gn01838335: 直接打開code解釋概念和想法，能說服teammember最重要
→ gn01838335: 重點是你的code人家改不改得多，而不是講一堆天花亂墜
→ gn01838335: 名詞
→ gn01838335: 公司同事不是來做模式研討的
推 chupiggy: 有人只會噓 也沒看到分享什麼東西出來
推 louise13: 感謝分享
推 nichinichi: 感謝作者帶起一股討論技術的新氣象
噓 pttuser: 變形是在變啥？抽象程度高有比作春夢的抽象還高嗎？
→ pttuser: 現在就是一堆人實作搞混或是認為抽象程度比玉山高
→ pttuser: 實作上亂七八糟，討論變形討論不完啦
→ pttuser: 每個人都能自己亂變一通
→ pttuser: 所以實作上把observer界定就是sync , one-to-many
→ pttuser: 把pub/sub界定就是async , many-to-many
→ pttuser: pub/sub實作上被廣泛應用的是mqtt 架構
→ pttuser: MQTT不是GOF所寫的observer pattern
→ pttuser: 原po你自己想想，你寫的observer怎麼實作facebook messag
→ pttuser: er?
噓 pttuser: 林北喜歡噓是不行膩？林北又要來gdb了
→ dreamnook: 所以你的立場就是observer只能sync 只能1-to-many
→ dreamnook: 激醬也只能加牛肉或加豬肉 不能牛豬混合這樣
噓 pttuser: 你要加個event driven作obsever async, one-to-many也沒
→ pttuser: 人反對阿，反正抽象嘛，變形嘛，高興就好了阿哈哈哈哈
→ robler: 開始語無論次了耶
→ robler: 實作上界定是誰界定 你自己嗎?
→ robler: 講話一點根據都沒有 你怎麼不講講你怎麼實作FB msger
推 wix3000: 壞掉了 50收
噓 pttuser: robler我這樣語無論次？看來你程度不高，真的不懂我在說
→ pttuser: 啥？
→ pttuser: 不說啦，反正不關我的事，掰啦哈哈哈哈
→ dreamnook: 所以你的立場的確就是激醬只能加牛肉或豬肉沒錯
推 m1309050: 只有自己是對的，在職場碰到這種人真的是災難
→ robler: 真的是惱羞成怒耶 笑死人 講不出道理就胡扯一通
→ robler: 講的東西半點根據都沒有 不是寫一堆專有名詞就叫懂好嗎
→ dreamnook: 是不是把network層和software層混在一起了(′・ω・‵)
推 tpstyle: 在職場碰到這種人真的是災難+1。
→ tpstyle: 原po加油，持續期待你的技術分享
噓 pttuser: dreamnook我講的是架構不是協議，看清楚………
→ dreamnook: 我當然看不清楚呀 所以我才一直在講激醬牛豬肉飯XD
→ dreamnook: 你有個根據也好 來源也行 回文也可以
→ dreamnook: 但我程度低只覺得你是observer就1-to-many sync固定
推 ns1234: 有分享有推 總比有人。。嗯
→ dreamnook: 趁building我隨意google:https://goo.gl/IdCoC4
→ dreamnook: 這篇就有在implementation表現出Observer與Pub/Sub不同
→ dreamnook: 我快速閱覽過的理解是Observer是直接針對Subject
→ dreamnook: Pub/Sub則是有個middle man在中間(broker)
→ dreamnook: 詳細解釋就看誰程度比較高了 我繼續苦勞去XD
推 gmoz: 這就是火大模式
推 Argos: 哈哈哈 開始了開始了 又是這種空泛的爭論 學模式學到走火入
→ Argos: 魔就是這種下場 哈哈哈
→ Argos: 某p還裝忙 明明閒得要死吧？噓文都快比原文字數多囉
推 kurtsgm: 其實我覺得sync/async根本不是重點吧......
推 tw88: 有看有推 感謝分享
→ ggBird: pttuser別笑破人覽趴了
推 gn01838335: 這一次我挺pttuse乾淨的code的確是樣
→ gn01838335: 但是要大家一致實作是很困難
→ dreamnook: 你的實作很困難是指Observer Pattern實作困難還是?
推 ripple0129: Observer是廣義的pub-sub，pub-sub是更具體化實際做法
→ ripple0129: ，兩個都沒對錯，看的是廣義與狹義罷了。講白了就是吵
→ ripple0129: 的是白馬非馬的概念。
推 ripple0129: 怕產生誤解的是我叫你買飯桌（pub-sub)，結果你買的是
→ ripple0129: 桌子(observer)，是桌子沒錯但不是我要的飯桌，這時就
→ ripple0129: 產生了名詞上造成的誤解。
推 gn01838335: 我覺得pttuser很care實作細節的精緻的。應該功力很強
→ gn01838335: 可否跪求大大的code
推 Frozenmouse: 結果連實作上是誰界定也講不清楚
推 blackie1019: 蠻認同pttuser是有料的。但要讓大家懂真的辛苦...
→ kightkids: 站在Subject得add(Observer)這點，覺得跟pub/sub不一樣
推 Frozenmouse: 我就不懂為何要執著於大廠怎樣，GoF當初把pub-sub當
→ Frozenmouse: 成observer別名，和現代的pub/sub怎麼實作，兩者到底
→ Frozenmouse: 有什麼衝突啊XD
推 Frozenmouse: 而且也不是天差地遠的那種，本質上也都還是訂閱啊…
→ dreamnook: 我是覺得多個Middle Man你還是要add(sub)
→ dreamnook: 只是這個middle man不負責產生notification
→ dreamnook: 而是負責把別的人給的notification(pub)傳給sub
→ dreamnook: 但把關係圖畫完後不會只有observable-observer的關係
→ dreamnook: 而是pub-middle man(broker)-sub 因而不同
→ dreamnook: 只是再打下去我覺得我只會產生更大的混亂了XD
推 Frozenmouse: 同樓上，概念還是subject->observer這樣，只是透過中
→ Frozenmouse: 間人介接XD
推 stosto: Pattern只是人家整理出來最長遇到問題而衍生出的樣板解法
→ stosto: 而已，dp哪個是打從娘胎就有的
→ gn01838335: 其實userptt講了應該用產品決定設計模式
推 ADYex: 推分享。設計模式重要的是它的精神，而不是死板板的說怎樣
→ ADYex: 怎樣寫才是什麼什麼模式。
推 frank11118: 推分享，但某人學到走火入魔了
推 Argos: 真的有料 就不會用那種態度這樣討論設計模式 有的大概只是
推 ADYex: http://i.imgur.com/2wXVcKa.jpeg
→ ADYex: 重構—向範式前進 第28頁。
→ Argos: 半點料 然後就自以為是 看那種狂噓人家的風格 是有多自卑
→ ADYex: 雖然這裡主要是講結構圖，但其實就是指同樣的設計模式並不
→ ADYex: 會只有一種實作方法。
→ Argos: 本來就是心法的東西 大觀念樓主也沒寫錯啥 硬要在那邊爭 所
→ Argos: 以我說走火入魔了 心已經容不下任何東西了 寫code寫到這樣
→ Argos: 也是蠻悲哀的
推 ADYex: 設計模式是拿來跟人溝通、改善程式、解決問題用的，不是拿
→ ADYex: 來死背名稱用的。
推 locklose: 要戰就發一篇，推文不易追蹤。
→ remmurds: 吵什麼 design pattern 名字實在很無聊
→ anr2: 程式能動比啥都重要
推 loveme00835: xD 能不能反射性地用出來才是關鍵
推 Csongs: 私心求pttuser發一篇幫助我們了解，小弟只能p幣贊助
推 Schaos: 糾結名詞真的有差嗎？理解後能靈活運用才是重要的。
推 sdyy: 糾結在名詞 狂噓人
噓 brucetu: 我認為pub/sub在程式及時間上解藕發佈與接收者，一般講觀
→ brucetu: 察者並不會要求你做個中間人來分離這兩者，我想pttuser
→ brucetu: 對於你將兩者說成是一樣東西不能認同原因也在此。
→ brucetu: 當然你可以說我的觀察者模式通常還會放個中間人做異步，
→ brucetu: 我的發佈訂閱也不一定非同步。就好像我牛肉炒飯通常改用
→ brucetu: 豬肉還芶芡，我豬肉燴飯有時候不芶芡。
推 KeySabre: 討論的時候求名詞精確 其實是好事 實作時當差不多先生的
→ KeySabre:  只是把債延後還
→ Jasonzheng: 其實觀察者一直都可用中間人啦...
→ Jasonzheng: 而且這不是我差不多先生 或是 「反正抽象、彈性」
→ Jasonzheng: 而是 原著就有提到這樣的用法喔
→ Jasonzheng: 但原著有提到 這是借鑒了 mediator 模式的觀念
→ Jasonzheng: 因此我當初撰文時並未補充
→ Jasonzheng: 而是想在未來的文中提及
→ Jasonzheng: 很抱歉..我的疏失造成各位誤會
→ Jasonzheng: 我這陣子會再補充進內文
→ KeySabre: 我沒說你是唷 別亂坐 XD 有人整理分享激發討論 我都很感
→ KeySabre: 激的