跳到主要內容

發表文章

目前顯示的是 7月, 2023的文章

【程式語言 - Go】使用簡易的「工廠方法」來相容DB不同版本的API

  圖片來源... 在進入主題之前建議先行閱讀「 【程式語言 - Go】來認識Google開發的程式語言… 」,初步認識一下Go語言是什麼? 容不容易學習? 才能夠更快的體會此篇章的目的。 當我們在進行軟體開發時,常常會需要有背後的資料庫系統來儲存我們的資料,而資料庫系統也會隨著時代的演進,進行大幅度的更新,那在這樣的時空背景之下,我們究竟要如何設計才能對於未來升級時較無痛的改動呢? 因為我們都知道一但程式架構需要大幅度的改動時就是開發人員噩夢的開始了…,為了我們美好的未來,只好認真學習一下軟體的設計模式了,避免沒日沒夜的工作消磨掉應有的生活品質。 雖然我們也可以使用別人開發好的Library來補上這一塊,我們只要注意版本的差異即可,But…理想的狀況之下,作者願意持續維護該套件,甚至是有著官方的支持,才能有持續更新的版本,否則一但失去了維護的狀況之下,要嘛就是自己接手過來修改,不然就是另外尋找替代方案來進行替換,但這些都是成本啊,要用什麼方法,就好好的審慎評估了,並不代表說自己設計一定最好,通常事情都是這樣的,有正就有反,沒有最好,只有最適合的一種策略。 那我們也知道平常使用資料庫時,無非就是新增、修改、刪除、查詢這四大方法為一個基礎,而後才會衍生各式各樣的統計啊…等的進階應用,那麼假設我們的系統非常的單純,只需要設計資料庫的基本方法時,我們可以這樣做… 那在進入主題之前不免俗的在傳教一下什麼是「工廠方法」,所謂工廠方法我們就想像成汽車工廠,一台汽車基本上要能夠「驅動」,因此「驅動」是所有車型最基本需要的實作方式,那汽車工廠只要設計好「驅動」的介面規格即可,至於子公司要生產什麼車都沒關係,只要將「驅動」的功能給時做出來就可以了。 圖片來源... 這樣有什麼好處呢? 嗯….,一開始確實感受不到什麼好處,甚至設計時不斷懷疑自己是不是大砲打小鳥的感覺,但當有一天資料庫的API大改版時,我們就會慶幸當初做了這樣的設計,除了讓改動幅度傷害降到最低之外,測試的時候也能夠根據資料庫的版本切換不同的生產工廠,怎麼做呢? 就讓我們繼續的學習以下的實作細節。 這邊會以Elasticsearch資料庫搜尋引擎為例來進行示範,我們不需要包山包海的實作,只取其中的 _search 、 GET document 、 _update ...等部份的API進行即可。 其實原理很簡單,假設我們今天