乙個合格的程式設計師,別再一招if else走天下了

2021-10-02 03:54:27 字數 2098 閱讀 7107

哎,曾幾何時

想當年,其實我也特別鍾情於 if/else連環寫法,上來就是一頓sao操作,比如舉個好理解的簡單栗子:

一般來說我們正常的後台管理系統都有所謂的角色的概念,不同管理員許可權不一樣,能夠行使的操作也不一樣,比如:

系統管理員( role_root_admin):有 a操作許可權

訂單管理員( role_order_admin):有 b操作許可權

普通使用者( role_normal):有 c操作許可權

比如乙個使用者進來,我們需要根據不同使用者的角色來判斷其有哪些行為,這時候sao**出現了:

這樣當系統裡有幾十個角色時,那幾十個 if/else巢狀可以說是非常酸爽了…… 這樣一來非常不優雅,別人閱讀起來很費勁;二來則是以後如果再複雜一點,或者想要再加條件的話不好擴充套件;而且**一改,以前的老功能肯定還得重測,豈不瘋了……

所以,如果在不看下文的情況下,你一般會如何去對付這些令人頭痛的if/else語句呢?

當然有人會說用 switch/case來寫是否會優雅一些呢?答案是:毛區別都沒有!

接下來簡單講幾種改進方式,別再 if/else走天下了
有列舉為啥不用什麼角色能幹什麼事,這很明顯有乙個對應關係,所以學過的列舉為啥不用呢?

首先定義乙個公用介面 roleoperation,表示不同角色所能做的操作:

接下來我們將不同角色的情況全部交由列舉類來做,定義乙個不同角色有不同許可權的列舉類 roleenum:

接下來呼叫就變得異常簡單了,一行**就行了, if/else也灰飛煙滅了:

而且這樣一來,以後假如我想擴充條件,只需要去列舉類中加**即可,而不是去改以前的**,這豈不很穩!

除了用列舉來消除 if/else,工廠模式也可以實現
有工廠模式為啥不用不同分支做不同的事情,很明顯就提供了使用工廠模式的契機,我們只需要將不同情況單獨定義好,然後去工廠類裡面聚合即可。

首先,針對不同的角色,單獨定義其業務類:

接下來再寫乙個工廠類 rolefactory對上面不同角色進行聚合:

接下來借助上面這個工廠,業務**呼叫也只需一行**, if/else同樣被消除了:

這樣的話以後想擴充套件條件也很容易,只需要增加新**,而不需要動以前的業務**,非常符合「開閉原則」。

來,我們接著來,除了工廠模式,策略模式也不妨試一試
有策略模式為啥不用策略模式和工廠模式寫起來其實區別也不大!

在上面工廠模式**的基礎上,按照策略模式的指導思想,我們也來建立乙個所謂的策略上下文類,這裡命名為 rolecontext

很明顯上面傳入的引數 operation就是表示不同的「策略」。我們在業務**裡傳入不同的角色,即可得到不同的操作結果:

好了,先講到這裡吧,本文僅僅是拋磚引玉,使用了乙個極其簡單的示例來打了個樣,然而其思想可以廣泛地應用於實際複雜的業務和場景,思想真的很重要!寫**前還是得多思考一番,考慮是否有更具可擴充套件性的寫法!

做乙個合格的程式設計師吧

1 總結自己一天任務的完成情況 最好的方式是寫工作日誌,把自己今天完成了什麼事情,遇見了什麼問題都記錄下來,日後翻看好處多多 2 考慮自己明天應該做的主要工作 把明天要做的事情列出來,並按照優先順序排列,第二天應該把自己效率最高的時間分配給最重要的工作 3 考慮自己一天工作中失誤的地方,並想出避免下...

乙個合格的程式設計師該做的事情

乙個合格的程式設計師該做的事情來自 csdn 選擇自 mailbomb 的 blog 程式設計師每天該做的事 1 總結自己一天任務的完成情況 最好的方式是寫工作日誌,把自己今天完成了什麼事情,遇見了什麼問題都記錄下來,日後翻看好處多多 2 考慮自己明天應該做的主要工作 把明天要做的事情列出來,並按照...

乙個合格的程式設計師該做的事情

程式設計師每天該做的事1 總結自己一天任務的完成情況 最好的方式是寫工作日誌,把自己今天完成了什麼事情,遇見了什麼問題都記錄下來,日後翻看好處多多 2 考慮自己明天應該做的主要工作 把明天要做的事情列出來,並按照優先順序排列,第二天應該把自己效率最高的時間分配給最重要的工作 3 考慮自己一天工作中失...