談談我工作中的23個設計模式

語言: CN / TW / HK

作者:閔大為(天未)

從基礎的角度看,設計模式是研究類本身或者類與類之間的協作模式,是進行抽象歸納的一個很好的速成思路。後面閱讀設計模式後,為了加深理解,對相關圖片進行了描繪和微調。

從技術的角度已經有很多好的總結,本文會換一種角度思考,既然設計模式研究的是類與類的關係,我們作為工作的個體,一些工作中的策略是不是也可以進行類比,可以更好地去思考這些模式?答案是肯定的。

建立型模式 5

抽象工廠(Abstract Factory):多套方案

抽象工廠模式是對建立不同的產品型別的抽象。對應到工作中,我們的確應該具備提供多套方案的能力,這也是我們常說的,要提供選擇題。當你有這樣的前瞻意識,一般也會被打上思考較多的標籤,但是內在來說,的確想問題更加全面了。

1.png

生成器(Builder):善於分解

生成器模式是對一個個體的建立過程進行細分,拆解為不同的建立部分。這個對應到工作中,作為一些專案管理人員或者團隊管理者,需要將一個大泥球一樣的事務,合理分解,讓大家各司其職,充分發揮才能。同樣,我們對日常的工作內容,也可以按照結構去進行劃分,從而更有條理。

2.png

工廠方法(Factory Method):抽象思考

工廠方法模式是說將提供某一產品的過程進行抽象,通過介面的模式去規範出來。類似的,我們很多做事的過程,都是面向過程,沒有抽象提煉一下。如果經過進一步思考,那麼可以往上再提煉一個層次,發現事物的本質:到底在做什麼,我們的職責是什麼,提供什麼樣的價值。想的更清楚,做的也會更加準確。

3.png

原型(Prototype):傳承知識

原型模式是說,利用拷貝物件的方法,減少一些複雜的建立過程。這裡我們能夠學到的是,需要做好日常的積累,很多方案不是每次來都重寫,是可以在原來的方案上進行拷貝複用的。這個clone的過程,往往也是知識傳承的過程。如果有比較好的傳承機制,那麼會大大提升服務效率。

4.png

單件(Singleton):專注

單件模式是說在多執行緒的情況下,要保證物件只建立一遍,作為獨一無二的資源。這個我覺得,應該去review一下我們的工作模式,雖然我們常常要併發很多事情,但是如果處處被打斷,每件事都想幹好,那麼可能每件事都幹不好。我們要確保在某個時間段竭力地做好一件事。事件是一件件有效解決的,不是一起慢慢解決的。

5.png

結構性模式 7

介面卡(Adapter):適應能力

介面卡是為了結合原來的能力,適配新的介面服務,比如適配不同的協議入口。工作的時候,其實需要適應不同的人和事,有不同的工作方法方式,但是我們的核心能力是一樣的,都是解決對應的問題域。

6.png

橋接(Bridge):合理關係

橋接模式是將原來相互依賴的部分,通過上層介面再往抽象層提一下,減少類之間的直接合作,形成間接關係。這個到對應到工作中來說,有一種場景是,常常開發對開發去case by case解決問題。如果往產品邏輯層走一下,開發對產品,產品層面可能有更好的抽象。當然為了更好的服務體驗,這樣的解耦是不多見的,但是這樣的思考我們可能要get一下。

7.png

組合(Composite):遞迴思考

組合模式通過繼承和孩子節點,可以遞迴地去描述一個物件層次。這個對我們工作來說,要加深思考的層次,可以某個點拆開去再去思考,同時如果能夠在遞迴分解過程中抽象一些共性的點,就能找到一些規律。比如我們的需求分解,每個需求可以分解為子需求,子需求再往下看又可以遞迴分解。分解完之後,每個部分有這部分的owner去驅動他的下游,形成一個層次結構。

8.png

裝飾(Decorator):增量價值

裝飾模式是將原來的能力進行包裝,並提供新的行為。其實每次功能迭代,我們大多是在原來的基礎上新增新的功能。我們要定義好新的能力,首要前提是繼承、理解好原來的邏輯。這裡還想提的是,很多時候,我們只看到了我們複用了龐大的基礎能力,但是也要看到我們在專案中增量的貢獻,這是我們的閃光點。不要把“擰螺絲”真的看成了擰螺絲。

9.png

外觀(Facade):深入淺出

外觀模式是說我們不需要理解複雜的系統,而是通過一個外觀去操作。這裡我們的工作思路是,我們不用展示覆雜的細節,我們要提供一些高層的理解,彙報如此,系統的包裝也是如此。就比如,服務功能孤立來看,可能很多、很雜,但如果有一個統一的站點去引導包裝,那麼感覺會好很多,也會看上去有點收口和聚焦的感覺。

10.png

享元(Flyweight):善於連結

享元模式是說,當我們已經存在一些內容的時候,可以通過快取複用,而不是重新建立,減少開銷。我們在工作中也要做好積累,但是更要做好快取的key,通過怎麼樣的手段去連結到我們的工作中,是需要我們做好類目管理和持續積累的。

11.png

代理(Proxy):理解保護

代理是為了包裝一個類,對相關操作進行二次轉發或者進行一些管控。工作中來說,有些工作模式下,有時候我們可能會抱怨管理者代理了我們的決策等操作,但是換個角度想,他們保護了你不用直接被暴露在業務方側,能夠按照預期內的節奏提供服務,不會被主動設定一些預期外操作或私活。

12.png

行為型模式 11

責任鏈(Chain of Responsibility):能力與責任

責任鏈是說將請求讓佇列內的處理器一個個執行,直到找到可以執行的。這裡對我們工作的啟示是,我們常常抱怨我們得到的機會少,不能成為佇列內優先可以處理的處理器,總是處理人家不需要的。但是換個角度看,首先責任鏈裡面的處理器應該是正交的,大家應該各司其職。退一步來說,如果真的有重疊,那麼你應該努力提升自己,成為能力強的,從而提高佇列內的優先順序。

13.png

命令(Command):加強合作

命令模型是說將請求包裝為命令,這樣在執行的時候可以與具體的執行邏輯解耦。工作中來說,我們有時候不應該太關心一個事情是怎麼完成的,當交給別人完成時,信任他們即可,就是從解決問題的角度來看,不用事事親為,事事較真。但是這並不妨礙我們主動養成全域性視角,瞭解每個細節。合作才能影響更多的事情。

14.png

直譯器(Interpreter):加強理解

直譯器模式是說針對一套上下文,形成一套語言,可以通過解釋表示式含義的方式完成對應的任務。這裡來說,我們可以形成某個團體的領域語言,內部交流通過相關領域語言交流,可以增加交流效率。此外,其實不同層次都有不同層次的專業術語,有時候一個術語的解釋是一個方面的頓悟,還是要多瞭解工作內容本身。

15.png

迭代器(Iterator):橫向職責

迭代器模式是將集合的訪問功能獨立出來,通過迭代的模式去訪問。這種獨立職責的操作,工作中我們常常會看到,我們會將需求管理,缺陷管理,資金安全的一些事情獨立出來看。一個方面是這些功能塊從主體來說是比較內聚的,另一個來方面說,對工作職責的細分,可以讓大家把自己的事情幹好,發揮團隊作戰的效能:開發把開發幹好,測試把測試幹好,資損防護同學把資損防護幹好,整體也就做好了。

16.png

中介者(Mediator):協調能力

中介模式是說:當多個類之間要協調的時候,往往引入中介者進行協調,減少大家的知識成本。這個我們常常需要一些PM、PMO這樣的角色去管理專案,系統中也需要一些協調層去協調各個域。因此我們也注重培養協調事務、具備全域性觀的能力。

17.png

備忘錄(Memento):小步快跑

備忘錄模式是對操作的一些記錄,已被可以恢復到之前的版本。在日常工作中,我們常常需要及時備份、及時儲存、及時提交等操作,這樣在程式崩潰的時候可以快速恢復到之前版本。但從抽象來說,一些比較長時費力的事情,我們應該分解來做,及時鎖住部分收益。

18.png

觀察者(Observer):主觀能動性

觀察者模式是說我們通過註冊、回掉這樣的協作設計,完成變化通知的協作機制。這個工作中來說,換個角度思考,我們可以將一些被動的工作,變成主動的思考。比如:我需要幹某部分工作,從工作的角度來說,不得不做,從主動的角度來說,就是需要培養某塊的能力。如果對工作內容不太滿意,也可以溝通協調,而不是事後爆發,凡是都是可以主觀驅動的。

19.png

狀態(State):管理自己

狀態模式是說在不同的狀態下,有不同的處理行為。對工作中來說,我們可能有狀態好的時候,有狀態不好的時候,主觀的處理的手段是調整狀態。但是如果調整不過來,我們應該進行不同的操作。比如,腦子好的時候,想一些複雜問題;腦子嗡嗡的時候,做一些簡單整理。

20.png

策略(Strategy):理解決策

策略模式是說完成一個事情有不同的演算法,可以進行相關切換。我們在工作中,常常會提供不同的方案,不同的方案有不同的成本和收益,但是這些方案的選擇時候,往往不是我們能決定的,而是客戶client主動判斷的。

21.png

模板(Template):標準化能力

模版模式是說對一個執行過程進行抽象分解,通過骨架和擴充套件方法完成一個標準的主體邏輯和擴充套件。我們很多時候,做xxx平臺也都是這樣的:對過程進行標準化,對變化進行定義,形成一個平臺邏輯和業務擴充套件,完成一個產品模版。只是說這個模版是站點,還是擴充套件點,還是其他的展示形式。這樣標準化的能力也是需要長期訓練的。

22.png

訪問者(Visitor):學會放手

訪問者模式是說把對元素的訪問操作交給訪問者來操作,因為對訪問者來說常常有不同的訪問行為。在工作中,往往我們只能陳述事實,這個內容消化後,每個人都有自己的理解。程式碼協作也是一樣,比如:頁面到底長什麼樣,其實還是要交還給業務本身,我們應該專注於提供基礎的能力。

23.png

總結

作為開發者,我們對於如何寫出優雅的程式碼,表示疑惑。因為常常背後是複雜的問題域,優雅的設計往往產生於區域性,很難整體都很優雅。

作為工作者,我們對於如何做出好的表現,表示疑惑。因為背後常常是綜合素質與機遇的結合,好的結果往往產生於一個階段,長期需要較快且持續的成長。

但是,如果我們有一些指導性的原則,往往我們能夠明白事務的折中點,做出更加合理的設計,以及更加關鍵的貢獻。