Golang 設計模式

2021-08-15 06:47:26 字數 4052 閱讀 9302

策略模式(strategy)

簡介

策略模式:將演算法或操作抽象成實現共同介面、可以被替換的類,實現邏輯和具體演算法的解耦。

·將各種行為抽象成演算法,封裝演算法為物件;

·演算法實現共同介面,呼叫者呼叫時不考慮演算法具體實現,呼叫介面方法即可;

·呼叫者可隨時替換此演算法物件; 

應用場景

·多個方法選擇一使用,且它們會被隨時替換;

·方法沒有共性,使用繼承會有大量重寫,使用介面會有大量重複使用;

實現

1.兩個演算法:氣泡排序和快速排序;

2.抽象氣泡排序和快速排序為演算法物件,實現演算法介面,擁有used()被使用方法;

3.計算器計算時不用理會是什麼演算法,呼叫used()即可;

觀察者模式(observer)

介紹

觀察者模式:主題主動向觀察者推送變化,解決觀察者對主題物件的依賴。

·觀察者實現被通知介面,並在主題上註冊,主題只儲存觀察者的引用,不關心觀察者的實現;

·在主題有變化時呼叫觀察者的通知介面來通知已註冊的觀察者。

·通知方式有推(主題變化時將變化資料推送給觀察者)和拉(主題值告知變化,觀察者主動來拉取資料);

應用場景

·乙個主題,多個觀察者,主題的任何變動,觀察者都要第一時刻得到;

·觀察者獲取主題變化困難,定時不及時,輪詢消耗大;

·觀察者可以隨時停止關注某主題;

實現

1.張三和李四是記者,他們需要及時了解城市發生的新聞;

2.張三和李四在電視台註冊了自己的資訊;

3.城市發生了新聞,電視台遍歷註冊資訊,通知了張三和李四;

4.李四退休了,在電視台登出了自己的資訊;

5.城市又發生了新聞,電視台只通知了張三;

裝飾者模式(decorator)

介紹

裝飾紙模式:包裝乙個物件,在被裝飾物件的基礎上新增功能;

·裝飾者和被裝飾物件擁有同乙個超類,裝飾者擁有被被裝飾物件deep所有外部介面,可被呼叫,外界無法感知呼叫的是裝飾者還是被裝飾者;

·裝飾者需要被裝飾者作為了引數傳入,並在裝飾者內部,在被裝飾者實現的基礎上新增或修改某些功能後,提供同被裝飾者一樣的介面;

·裝飾者也可被另乙個裝飾者裝飾,即潛逃裝飾;

·裝飾者是一群包裝類,由於裝飾的複雜性,會多出很多個裝飾者小類。

應用場景

·物件需要動態新增和修改功能;

·功能改變後不影響原物件的使用;

實現

1.在商店內,花作為被裝飾者物件,紅絲帶和盒子作為花的裝飾者;

2.花、紅絲帶、盒子有共同的超類"商品",它們都能被賣掉;

3.我們可以在紅絲帶裝飾過花後,在用盒子再包裝一次;

4.包裝後的花,顧客買時也不會收到任何影響;

工廠模式(factory)

介紹

工廠模式:是物件的生產器,解耦使用者對具體物件的依賴;

·實現依賴倒置,讓使用者通過乙個產品工廠依賴產品的抽象,而不是乙個具體的產品;

·簡單工廠模式:接收引數並根據引數建立對應類,將物件的例項化和具體使用解耦;

·抽象工廠模式:將工廠抽象出多個生產介面,不同型別的工廠呼叫生產介面時,生產不同型別的物件;

·簡單工廠常配合抽象工廠一起使用;

場景

·根據不同條件需求不同的物件;

·物件例項化的**需要經常修改;

實現

1.簡單工廠:向鞋廠內傳入不同型別(布製),鞋廠會生產出不同型別的鞋子(布鞋);

2.抽象工廠:有兩座鞋廠:李寧鞋廠、adidas鞋廠、它們能生產對應各自的鞋子;

3.搭配使用:向不同的抽象工廠(李寧)傳入不同的型別(運動型別),會生產出對應品牌對應型別的鞋子(李寧運動鞋);

單利模式(singleton)

介紹

單例模式:保證同乙個類全域性只有乙個例項物件。

·在第一次例項化會使用靜態變數儲存例項,後續全域性使用此靜態變數;

·一般將構造方法私有化,狗仔方法新增final關鍵字無法被重寫,新增乙個類的靜態方法用於返回此例項;

·在多個執行緒時應該考慮併發問題,防止兩次呼叫都被判定為例項未初始化而重複初始化物件;

場景

·全域性共享同乙個例項物件(資料庫連線等);

·某一處對此物件的更新全域性可見;

實現

1.利用go包中的可見性規則來隱藏物件的例項化許可權;

2.使用包變數儲存例項物件,獲取例項時判斷是否已經例項,如為nil,例項化物件並返回,如果有值,直接返回值;

3.待用鎖實現go routine併發時的問題;

命令模式(command)

介紹

命令模式:將乙個命令封裝成物件,解耦命令的發起者和執行者;

·命令物件實現命令介面,命令發起者例項化命令物件,並傳遞此物件,並不關心此物件由誰執行;

·命令執行者只負責呼叫命令物件的執行方法即可,不關心物件是由誰生產的;

·與策略模式不同之處:策略模式是通過不同的演算法做同一件事情,而命令模式則是通過不同的命令做不同的事情;

場景

·命令發起者與執行者無法直接接觸;

·命令需要撤銷功能,卻不易儲存命令執行狀態資訊時;

實現

1.指揮官建立了乙個「從樹下跑到草地上」的命令;

2.命令被分配給張三執行,張三作為軍人,接到命令後不管命令的具體內容,而是直接呼叫命令的執行介面執行;

3.指揮官發布了撤銷指令,張三又從草地上跑到了樹下;

介面卡模式(adapter)

介紹

介面卡模式:包裝物件提供乙個介面,以適配呼叫者。

·介面卡通過乙個中間物件,封裝目標介面以適應呼叫者呼叫;

·呼叫者呼叫此介面卡,以達到呼叫目標介面的目的;

·介面卡模式與裝飾者模式的不同之處:介面卡模式不改變介面的功能,而裝飾者會新增或修改原介面功能;

場景

·提供的介面與呼叫者呼叫的其他的介面都不一致;

·為乙個特殊介面修改呼叫者的呼叫方式得不償失;

實現

1.張三是個正常人,他能通過說話直接地表達自己;

2.李四是個聾啞人,他沒法直接表達自己,但他會寫字;

3.筆記本作為乙個介面卡,用筆記本"包裝"了李四之後,當李四需要表達自己想法時,呼叫筆記本的"表達"功能,筆記本再呼叫李四的「寫字」的方法;

外觀模式(facade)

介紹

外觀模式:通過封裝多個複雜的介面來提供乙個簡化介面來實現乙個複雜功能;

·外觀模式是通過封裝多個介面來將介面簡單化;

·外觀模式不會改變原有的多個複雜的單一介面,這些介面依然能被單獨呼叫,只是提供了乙個額外的介面;

·外觀模式與介面卡模式的不同之處:外觀模式是整合多個介面並新增乙個簡化介面,介面卡是適配乙個介面;

場景

·實現某一功能需要呼叫多個複雜介面;

·經常需要實現此功能;

實現

1.正常的衝咖啡的步驟是:磨咖啡豆、燒開水、倒開水攪拌咖啡;

2.我們經常需要直接衝咖啡,而不是使用單一步驟,每次喝咖啡時呼叫三個方法很麻煩;

3.封裝三個介面,額外提供了乙個"衝咖啡"方法,需要和咖啡時只需要呼叫一次衝咖啡的方法即可。

參考:

Golang設計模式 工廠模式

定義乙個用於建立物件的介面,讓子類界定例項化哪個類。工廠方法使乙個類的例項化延遲到子類。簡單工廠模式的最大優點在於工廠類中包含了必要的邏輯判斷,根據客戶的選擇動態例項化相關的類,對於客戶端來說,去除了與具體產品的依賴。如果是翻譯,讓客戶端不管用哪個類的例項,只需把翻譯型別 int 1,2,3 給工廠...

設計模式golang 工廠模式

建立物件的介面,讓其子類自己決定例項化哪個類,工廠模式使其建立過程延遲到子類進行。1.產品抽象介面 2.工廠建立產品方法 3.產品例項 選銀行借錢的例子,資質方法根據你的收入等其他情況給你選擇銀行。抽象產品介面 type bank inte ce 具體銀行產品例項 type bjbank struc...

設計模式golang 命令模式

將乙個請求封裝為乙個物件,從而使我們可用不同的請求對客戶進行引數化 對請求排隊或者記錄請求日誌,以及支援可撤銷的操作。命令模式是一種物件行為型模式,其別名為動作 action 模式或事務 transaction 模式。1.命令抽象介面 2.請求結構體 乙個盒子上的按鈕執行 命令抽象介面 type c...