iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 21
1
自我挑戰組

Let's Eat GO ! 實務開發雜談by Golang系列 第 21

Day21 .[心得與討論篇] struct 設計解析 - 以melody package (1)

接下來筆者的系列文,會一連串圍繞在struct的設計分析上,接下來的內容都是自己的感想,並非有所謂的正確答案。

初步解完了interface之後,我們來繼續試圖了解大大們寫的package,到底其中有什麼秘密,有哪些值得我們學習的部分。

我挑選的對象是melody,一個在gorilla package進一步包裝的package,而gorilla是一個websocket的主流開發套件。

melody github連結

gorilla github連結

melody只是多包裝一層,增加使用上的易用性,而非實作websocket的連線及管理,實際業務處理不會太難,請各位放心,裡面不是什麼妖魔鬼怪XD。

第一步下手位置

筆者的心得是,要了解golang的code,那麼最多以package為單位,理由是除了package的內容範圍本身可能就有一定規模之外,golang的設計限制也不會讓人有辦法,寫出數個package業務處理強烈耦合在一起的狀況。

那麼在一個package裡面呢?該從何處下手。

除了文件的描述package的目的和內容外,可以先看_test.go的檔案。

_test.go的內容,本來很有可能就比原本的程式碼還長還多,因為一種業務處理本來就有可能多種應用的案例。

我們並不需要細看,只需要稍微瀏覽有什麼method name,稍微知道package有哪些動作,大概在處理什麼事情,基本上對package就有一個初步的了解。

再經過查看_test.go相關檔案後呢?

筆者認為就是來找業務主體的時候了,承接前面幾篇介紹interface的想法,程式裡面會有許多業務處理,每種業務抽象出來,會有個主體主持著,通常是以struct為單位,每個struct自然有屬於它自己的變數和method,每個主體專心處理自己要處理的業務,並且不跟其他的主體有強烈的耦合。

所以在看過文件和test file之後,我們第一步就是要來找出package內的業務主體,可能一個或多個,一開始也不用全部挖出來就好,知道最龐大的,最核心的幾個就行,並且嘗試對於他們彼此之間,互相的關係試想一些概念。

筆者開始接觸websocket的開發工作的時候,其實對websocket沒什麼概念,一開始是用反查的方式去了解melody。

如下面這段,進到程式的商業邏輯處理之前,是透過有個HandleMessage的method,將連線資訊送過來,melody.Session就是我想知道的第一個重點。

// HandleWSReadMsg 掛載websocket收到client message的處理
func HandleWSReadMsg() {
	// 接收client 傳來的訊息
	Serverset.WSServer.HandleMessage(func(s *melody.Session, msg []byte) {
		Entry(s, string(msg))
	})
}

下一篇開始,我們就一起從melody.Session開始,試著分析melody的架構設計吧。


上一篇
Day20 .[心得與討論篇] chain 鏈式寫法
下一篇
Day22 .[心得與討論篇] struct 設計解析 - 以melody package (2)
系列文
Let's Eat GO ! 實務開發雜談by Golang30

尚未有邦友留言

立即登入留言