接下來筆者的系列文，會一連串圍繞在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的架構設計吧。