方法一：設(shè)計(jì)模式是為了消除繼承

大部分設(shè)計(jì)模式，是讓你在在面向?qū)ο蟮幕A(chǔ)上盡量消除繼承的手段。所以，如果你用了一些設(shè)計(jì)模式，減少了繼承，那你八成用對(duì)了。如果你用了一大堆設(shè)計(jì)模式，然而繼承卻越來越頻繁，那你100%用錯(cuò)了。

之所以說大部分，是因?yàn)閭€(gè)別設(shè)計(jì)模式（比如享元模式）是為了解決特殊場景特殊問題而生的。

方法二：良好的設(shè)計(jì)應(yīng)該利于測試

一個(gè)設(shè)計(jì)合理的系統(tǒng)，因?yàn)榻怦畛浞?#xff0c;各個(gè)模塊獨(dú)立性強(qiáng)，所以單元測試應(yīng)該是比較容易寫的。如果你用了一大堆設(shè)計(jì)模式，卻發(fā)現(xiàn)給你寫的類編寫單元測試用例非常困難，那你一定是用錯(cuò)了。

方法三：多態(tài)是更好的if

多態(tài)的本質(zhì)是運(yùn)行期動(dòng)態(tài)決定程序的分支走向，也就是“更好的if”，而設(shè)計(jì)模式，至少是《設(shè)計(jì)模式》那本書中提到的那些模式，基本上是基于多態(tài)的。所以如果你合理的利用設(shè)計(jì)模式，你設(shè)計(jì)出的代碼應(yīng)該有較少的if，如果你的代碼越使用設(shè)計(jì)模式if越多，或者更直觀地說，縮進(jìn)越多，你一定犯了錯(cuò)誤。

方法四：看不懂的模式先不要用

有些模式是很容易用錯(cuò)的，比如visitor模式，其實(shí)是為了解決java不支持double dispatch而存在的，然而其邏輯很晦澀。所以當(dāng)你還在懷疑自己是否用對(duì)了設(shè)計(jì)模式的時(shí)候，你不應(yīng)該使用這樣的模式。

方法五：大部分類繼承都是錯(cuò)誤

類繼承總的來說只有1.5種正確的打開方式：

• 第一種叫做模板方法（template method），是設(shè)計(jì)模式之一。這種模式說的是基類在一個(gè)抽象的層面實(shí)現(xiàn)了公有方法a，a依賴私有方法b，而b的實(shí)現(xiàn)是子類的工作。這種模式下，子類實(shí)現(xiàn)的虛方法b是不應(yīng)該被外界調(diào)用的。當(dāng)然有一種極端情況，b即使a本身（比如react中的render），此時(shí)模板方法蛻化為普通的多態(tài)。

• 第二種叫做mixin，類a通過繼承一個(gè)基類b，獲得某種相對(duì)獨(dú)立的能力。然而這其實(shí)是一種不太好的設(shè)計(jì)，尤其是在需要mixin多種能力的時(shí)候，更合理的方式其實(shí)是在a內(nèi)部創(chuàng)建b的實(shí)例。只是在比較簡單的場景中，我們可以用繼承糊弄一下，所以只能算0.5種。

除此之外，使用類繼承基本上可以認(rèn)為是錯(cuò)誤的設(shè)計(jì)。

由此我們可以推論，在es6流行導(dǎo)致運(yùn)行時(shí)mixin寫法在前端不流行之后，前端代碼中出現(xiàn)了一些新的設(shè)計(jì)錯(cuò)誤。

方法六：不要模仿java的寫法

設(shè)計(jì)模式是一回事，設(shè)計(jì)模式的實(shí)現(xiàn)是另一回事，這一點(diǎn)很重要。比如著名的觀察者模式（observer），在java中有大量應(yīng)用。然而我們常見的觀察者模式樣板代碼之所以長那個(gè)樣，是因?yàn)閖ava中缺乏事件訂閱系統(tǒng)。在c++/c#以及js中實(shí)現(xiàn)觀察者模式，就沒必要那樣寫。因?yàn)閏++有std:function，c#有委托，而js函數(shù)干脆就是對(duì)象。

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的C# 子类实例化基类 基类使用不了子类的方法_老话题：6个方法，检验你有没有正确使用设计模式...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。