隨便講講我的理解。
callback概念解釋
這是非常普通的一次方法呼叫(method call):
一般來說,method()的呼叫耗時很短,也就幾毫秒。但如果method()內部涉及磁盤IO或者method()幹脆就是網絡呼叫(網絡IO),可能就比較耗時了。至於多久才稱得上「耗時」,不太好定義。當前案例中,不妨理解為:客戶端無法忍受得到最終結果所耗費的時間。
如何解決耗時操作呢?你可能很容易就想到「異步」:
這裏的「異步」,指的是狹隘的「開啟一個子執行緒」。但是上面這個圖 並不完整 ,原本的程式碼裏method()是有result的:
你可能很容易就想到了兩種方案:
但實際上,對於呼叫方而言兩種方式是一樣的,它都要等待這個method耗時操作完成才能收到result,然後才能執行後面的domething later操作。
於是產生了矛盾:
比較好的處理方式是:
既然do something依賴於method的result,那麽do something應該和method共同處理,所以我把do something挪到method內部怎麽把do something挪到method裏面呢?
由於do something的需求各種各樣,是不確定的,不能在method裏寫死。為了能讓method()幫我們執行自訂的操作, method()必須再提供一個入參:
callback()具有特異性,只有呼叫方才知道要做什麽樣的處理,所以要定義在呼叫側,也就是和main()在一塊。
callback與設計模式
callback和策略模式很像,但個人覺得還是細微差別,主要是出發點不同。
這是callback:
這是策略模式:
你要說策略模式「有call有back」,所以也算callback,其實也說得通...但兩者出發點是不同的。當前案例可能看不出來,再舉一個例子可能更好理解。
比如跨系統的callback:
這個時候你很難稱之為「策略模式」。
還有觀察者模式也是如此,看起來也和callback很像,但出發點也多少有點區別。觀察者模式出發點是當事件源發生改變時收到通知,而callback更像是有妥協的步驟拆分。
當然,還是那句話,你要是覺得這幾個本質是一樣的,那就這麽認為也無妨,個人覺得沒必要死扣定義。
callback與IO模型
很多人也學習過NIO和AIO,特別是AIO,定義了一個CompletionHandler介面:
當某個I/O操作完成時,會自動回呼completed(),我們實作completed()完成自己要做的操作。
總的來說,callback可大可小,宏觀的有JVM內的回呼函式、系統間的回呼介面,微觀的有作業系統的回呼機制,甚至脫口秀也有callback。
博主最近新寫的小冊,圖文並茂,通俗易懂:
還有2024年新寫的【設計模式那些事兒】: