Design Pattern
「設計模式」這個詞出自 Christopher Alexander 的《建築模式語言》，這本書出版於 1977 年，主題圍繞著建築，城市設計和社區宜居性。作者 Alexander 是一名建築師，他在意的是，能不能找到一種切實可行的模式語言，讓讀者用以設計辦公室、車庫或公共建築。 儘管這樣的期待難免於可操作性，但在另一方面，Alexander 同時是名評論家跟創作者，在創作的過程中，他也想知道，現實繁複的表象下，是不是存在某種共通性，能用於解釋建築間特定的規律？我們可以看到作者羅列出 253 個模式，像是活動中心(30)、墓地(70)與啤酒館(90)，Alexander 說：「每一模式描述我們周圍環境中一再發生的某項問題，接著描述解決該問題的關鍵所在，如此一來，你就能上萬次利用這種解決方式，而不必每次從頭來過。」 如同描述資料的資料稱為「後設資料(metadata)」，描述語言的語言稱為後設語言，而 Alexander 給這套後設語言起的名字是「
Go
相信平常開發時，即使沒真的用到，也會聽別人提起「依賴注入」的概念。我們都知道依賴注入的目的是解耦模組間的依賴，但具體來說，依賴注入應該要怎麼進行呢？Go 對於依賴注入有什麼比較好的實踐呢？這篇就來談談 Go 相關的依賴注入話題。 常見的實踐方式 講到依賴注入，從 OOP 的觀點來看，可以回到 Martin Fowler 的 SOLID 原則，其中的 Dependency Inversion Principle 落實到編程中，就是依賴注入。James Grenning 曾經簡單扼要說明 DIP 原則的出發點 Martin tells us that high-level modules shouldn’t depend on low-level modules. 這裡，高層級的模組指的是商業邏輯的實現。依賴反轉原則之所以重要，
Go
Observer Pattern 是物件導向常用的架構，例如多個 Chart 與單一 Data Source 的互動，就可以使用 Observer Pattern 設計，好避免資料不同步的問題。而且 Observer Pattern 可以切開 Subject 跟 Observer，讓個別模組的功能更明確，修改副作用更小。 Golang 的哲學是簡單，語言上更強調小元件的延展與復用，例如使用組合取代繼承，使用 Goroutine 取代 Thread 等。本文會講解怎麼使用 channel 來實現 Observer Pattern，或者更現代的說法，實現 Publish/Subscribe 的架構，來建構彼此獨立的模組。 Introduce Observer Pattern 先來對 Observer Pattern 做個解說。
Go
進行後端程式開發時，常會使用到 Golang 的 http 標準庫。例如要對某個 URL 進行處理時，會用到 http.Handle("/foo", fooHandler) 可以想像，如果沒有 http 庫，就需要使用大量的 if else 來對 URL 判斷，大幅降低程式碼可讀性。http 庫對 URL 進行 function 註冊的設計模式，不僅可以使用在後端開發，也能應用於更普遍的情境。對於要對同類型資訊進行不同處理的例子，都可以使用這個設計模式。 本文會用 Golang 來開發一個類似 http middleware 的程式，處理自訂的訊息格式，藉由這過程，也順便走一次 http 庫的路由設計原理。 Build a