假設(shè)有一個(gè)簡單的整數(shù)計(jì)算器,只支持加法和乘法運(yùn)算。它將接收一個(gè)整數(shù)生成器和一個(gè)作為加法器或乘數(shù)的整數(shù)作為其輸入?yún)?shù),并對來自生成器的每個(gè)元素應(yīng)用相應(yīng)的計(jì)算。我認(rèn)為下面的粗略序列圖恰當(dāng)?shù)孛枋隽诉@個(gè)邏輯。但是當(dāng)我使用 goroutines 和 channels 來實(shí)現(xiàn)相同的邏輯時(shí),直接的方法/函數(shù)調(diào)用關(guān)系消失了,因?yàn)?goroutines 使用通道來發(fā)送和接收數(shù)據(jù)。generator := func(integers ...int) <-chan int { intStream := make(chan int) go func() { defer close(intStream) for _, i := range integers { intStream <- i } }() return intStream}multiply := func(intStream <-chan int, multiplier int) <-chan int { multipliedStream := make(chan int) go func() { defer close(multipliedStream) for i := range intStream { multipliedStream <- i*multiplier } }() return multipliedStream}add := func(intStream <-chan int, additive int) <-chan int { addedStream := make(chan int) go func() { defer close(addedStream) for i := range intStream { addedStream <- i+additive } }() return addedStream}intStream := generator(1, 2, 3, 4)pipeline := multiply(add(intStream, 1), 2)for v := range pipeline { fmt.Println(v)}誕生的goroutinegenerator作為生產(chǎn)者發(fā)送整數(shù);add和中誕生的協(xié)程multiply既是生產(chǎn)者又是消費(fèi)者;他們接收整數(shù),處理它們,并將它們放入新的通道中。最后用兩個(gè)channel把這3個(gè)goroutine連接成一個(gè)pipeline,但是我沒有想到要呈現(xiàn)的一目了然。有沒有一種面向goroutines的UML圖?
1 回答

慕田峪7331174
TA貢獻(xiàn)1828條經(jīng)驗(yàn) 獲得超13個(gè)贊
在這個(gè)領(lǐng)域沒有放之四海而皆準(zhǔn)的方法。這完全取決于您希望在設(shè)計(jì)中將重點(diǎn)放在何處:
如果你想堅(jiān)持 goroutine 是輕量級線程這一事實(shí),并且在消費(fèi)的通道(緩沖或非緩沖)上,你可能會對活動圖感興趣?;顒訄D也適用于突出功能設(shè)計(jì)中的值流(即對象流)。
如果你想顯示對象(包括仿函數(shù))在特定場景中如何交互,保留序列圖,但完成它以顯示發(fā)生了什么:你至少需要一些消費(fèi)者和生成器之間的消息(這對應(yīng)于通過通道:箭頭不僅是函數(shù)調(diào)用;它們是消息,可以對應(yīng)于函數(shù)調(diào)用,也可以對應(yīng)于其他形式的通信)。如果頻道非常重要,您甚至可以考慮為其添加一條 liefline:這將解決您表達(dá)的大部分問題。
不相關(guān):使用 UML 圖可視化記錄低級代碼,或進(jìn)行某種可視化編程是完全有效的,但往往會創(chuàng)建非常復(fù)雜的圖表,比代碼更難閱讀。這可能不是最好的目的。
- 1 回答
- 0 關(guān)注
- 114 瀏覽
添加回答
舉報(bào)
0/150
提交
取消