摘要:在開發(fā)設(shè)計中有一些常用原則或者潛規(guī)則,根據(jù)筆者的經(jīng)驗,這里稍微總結(jié)一下最最常用的,以饗讀者。是處理復(fù)雜性的一個原則。參考六大設(shè)計原則里氏替換原則奧卡姆剃刀如有問題可以通過郵件微信聯(lián)系我。
在開發(fā)設(shè)計中有一些常用原則或者潛規(guī)則,根據(jù)筆者的經(jīng)驗,這里稍微總結(jié)一下最最常用的,以饗讀者。
DRY這里的DRY是Do Not Repeat Yourself的縮寫。具體解釋參見 ,嚴(yán)謹(jǐn)?shù)亩x是 Every piece of knowledge must have a single, unambiguous, authoritative representation within a system,意思是:任何一部分知識在系統(tǒng)中必須只有單一的,清晰并且權(quán)威的展示。???這是啥意思,沒懂。簡單說就是不要重復(fù)自己任何一部分的工作。比如說,有一段代碼是用于清除字條串中的HTML符號,在多個程序中會用到此功能,如果每個地方都使用如下代碼
html = html.replaceAll("<.*?>","") html = html.replaceAll("?",""); html = html.replaceAll("&"."");
如果是只有2,3個地方用到(Martin曾經(jīng)提到過Rule of three,意思是一段代碼如果被copy3次以上就應(yīng)該重構(gòu)到一個多帶帶的子方法中),你可能就直接復(fù)制過來用,但是想想是2,3百個地方用到呢?如果上面需要再做個修改(如下),你是不是要去這個2,3百個地方去改代碼。
html = html.replaceAll("<"."<"); html = html.replaceAll(">".">");
所以這個DRY的規(guī)則就是推薦使用 子方法 的方式,這樣只需要修改一次即可. 與之類似的編程思想有 DIE(Duplication is Evil),SPoT(Single Point of Truth), SSOT (Singel Source of Truth) 。 題外話,和DRY對應(yīng)的是WET,意思是 "write everything twice"(任何東西都寫兩遍)或者"we enjoy typing" (我們就是喜歡打字編碼)?!?-)
KISSKISS 是 Keep it simple, stupid (或者Keep it short and simple )的簡稱。意思是在設(shè)計時保持簡約,通俗。這個很像是現(xiàn)在推暢的“極簡風(fēng)”。
使用KISS有什么好處呢?如下是其中的一些:
你可以更快的解決更多的問題
你可以使用更少的代碼來解決復(fù)雜的問題
你可以寫出更高質(zhì)量的代碼
你可以創(chuàng)建更大的系統(tǒng),更好的去運維
你的代碼將更加靈活,當(dāng)有新需求時可以更好的支持?jǐn)U展,修改或者重構(gòu)
等等
在軟件設(shè)計領(lǐng)域, 有一些技術(shù)具體實現(xiàn)這個精髓,比如 DDD (Domain Driven Design),TDD (Test Driven Develop),這個使代碼集中在真正需要的功能上,而不需要其他額外的。另外一個建議是 不要試圖通過注釋來提高代碼的可讀性,而應(yīng)該從代碼本身提高。比如如下是不太好的變量定義
// i is for "counter" and j means total sum int i, j;
而如下是好的設(shè)計
// more intuitive one int counter,sum;
與此相呼應(yīng)的是稱作 奧卡姆剃刀 或者 簡約之法則:
Occam"s razor
The simplest (explanation|solution) is usually the best one.
往往最簡單的解決方案是最好的解決方案
具體到以Java為例的程序設(shè)計,如下有一些實踐KISS的建議
首先,認(rèn)清自己,不要認(rèn)為自己是個天才,這往往是你犯的第一個錯。
把你的工作打散成幾個子工作,每個部分不會耗費超過4-12個小時去完成
把一個問題分成幾個小的子問題,每個問題可以通過1個或者只要幾個類就能解決。
保持每個方法只做一件事,并且不要超過30-40行的代碼量
保持每個類的體積不要太大。
不要害怕扔掉不用的代碼。就像家里用不到的東西就及時扔掉一樣。
New Jersey style (Worse is better)新澤西風(fēng)格,也叫做“Worse is better”。此原則指出,系統(tǒng)的質(zhì)量不會因為新功能的增多而提高。 比如一個軟件,只提供一些功能,但是用戶很方便使用,有可能比一些提供了非常多令人眼花繚亂功能的“大雜燴”似的軟件。比如像 Linux下面的 vi/vim, 瀏覽器中的Chrome.
SOLIDSOLID是幾個編程哲學(xué)的總稱,即 SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) ,下面我們分別解釋一下:
Single responsibility (SRP)單一功能原則。Robert描述這個為“A class should have only one reason to change.”,即修改一個類(或者模塊)有(且只能有)一個理由。簡單說就是 一個類或者模塊只能負(fù)責(zé)一個功能。舉個例子,有一個模塊負(fù)責(zé)生成一個報表,可以想像可能有兩個理由去修改此模塊,第一,報表的內(nèi)容要變,第二,報表的格式要改。這兩個改動是出于不同的理由,一個是內(nèi)容的一個美化版面的。 而 “單一職責(zé)” 規(guī)則認(rèn)為這是兩個不同的職責(zé),因此應(yīng)該分成兩個不同的子模塊。如果把兩件事情放在一起,并且不同的改動是出于不同的原因,這種設(shè)計是不好的。此規(guī)則方便系統(tǒng)各模塊間解耦合。
Open/closed principle (OCP)開閉原則。Bertrand描述為“"software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";”,也就是說對于一個實體(類,模塊,方法等)允許在不修改源代碼的前提下擴展它的功能行為。即,你可以把 新代碼放到新的類或者方法中,新類通過繼承來重用已有代碼及功能。而 已有的代碼只有在修bug時才去修改。 此原則主要用于降低在添加新加功能時引入新的bug的風(fēng)險。
The Liskov Substitution Principle (LSP)里氏替換原則. 原文是 “Derived classes must be substitutable for their base classes.”,意思是,派生類(子類)對象能夠替換其基類(超類)對象被使用。 比如說,如果 S 是T 的子類, 那么任何T類的具體實現(xiàn)對象都可以替換S的實現(xiàn)對象出現(xiàn)的地方,具體的調(diào)用者也不知道具體是父類還是子類,還不會出現(xiàn)任何錯誤。比如下圖,調(diào)用者可以2來替換1的地方 。
Interface segregation principle (ISP)接口隔離。原文是 many client-specific interfaces are better than one general-purpose interface. 意思是多個特定客戶端接口要好于一個寬泛用途的接口。Make fine grained interfaces that are client specific. 應(yīng)該定義粒度合適的一系列接口(像下圖),以便于每個客戶去實現(xiàn)具體的功能請求。換句話說是,客戶(client)不應(yīng)該必須去依賴于它用不到的功能方法。此原則的目的是系統(tǒng)解開耦合,從而容易重構(gòu),更改和重新部署。
Dependency inversion principle (DIP)依賴反轉(zhuǎn)原則. 原文是 One should “Depend upon Abstractions. Do not depend upon concretions.” 意思是 一個方法應(yīng)該遵從“依賴于抽象而不是一個實例”。該原則規(guī)定:
高層次的模塊不應(yīng)該依賴于低層次的模塊,兩者都應(yīng)該依賴于抽象接口。
抽象接口不應(yīng)該依賴于具體實現(xiàn)。而具體實現(xiàn)則應(yīng)該依賴于抽象接口。
這個就像是設(shè)計模式中的Adaptor適配器模式。下圖解釋了這個原理。
圖1中,高層對象A依賴于底層對象B的實現(xiàn);圖2中,把高層對象A對底層對象的需求抽象為一個接口A,底層對象B實現(xiàn)了接口A,這就是依賴反轉(zhuǎn)。
SOCSeparation of concerns,?即關(guān)注點分離。 是處理復(fù)雜性的一個原則。由于關(guān)注點混雜在一起會導(dǎo)致復(fù)雜性大大增加,所以能夠把不同的關(guān)注點分離開來,分別處理就是處理復(fù)雜性的一個原則,一種方法。這個與SOLID中的 SRP很類似。
YANGI是"You aren"t gonna need it"的縮寫,直譯是“你將來用不到它的”。這個是極限編程的一個編程思想。意思是說,永遠(yuǎn)不要因為 預(yù)計你會用到某個功能就去寫一段代碼去實現(xiàn),總是只有問題出現(xiàn)了,真的需要這個功能時才去寫。
參考DRY
六大設(shè)計原則--里氏替換原則【Liskov Substitution Principle】
SOLID)
how to keep code simple
奧卡姆剃刀
Apache KISS
Worse is better
如有問題可以通過郵件[email protected]/微信helloworld_2000聯(lián)系我。謝謝。
原文位于: http://cloudsdocker.github.io...
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/65122.html
摘要:何為設(shè)計設(shè)計哲學(xué)中講到的一些設(shè)計準(zhǔn)則設(shè)計準(zhǔn)則小即是美讓每個程序只做好一件事快速建立原型先滿足基本需求,再后續(xù)升級舍棄高效率而采取可移植性采用純文本來存儲數(shù)據(jù)可讀性好充分利用軟件的杠桿效應(yīng)軟件復(fù)用使用腳本來提高杠桿效應(yīng)和可移植性避免強制性的用 何為設(shè)計 《Unix/Linux設(shè)計哲學(xué)》中講到的一些設(shè)計準(zhǔn)則: 設(shè)計準(zhǔn)則 小即是美 讓每個程序只做好一件事 快速建立原型(先滿足基本需求,再后...
摘要:開篇金幣積分商城下稱商城是眾多內(nèi)的一個產(chǎn)品,隨著使用的用戶越來越多,商城對于用戶留存的提升,扮演著重要的角色做為提高用戶黏性的核心產(chǎn)品,在擁有很好用戶體驗的同時,也必須存在著一個高效穩(wěn)定的系統(tǒng)。分析上述兩點,得到結(jié)論按用戶進(jìn)行分庫分表。 開篇 金幣(積分)商城(下稱商城)是眾多App內(nèi)的一個產(chǎn)品,隨著App使用的用戶越來越多,商城對于用戶留存的提升,扮演著重要的角色;做為提高用戶黏性的...
摘要:何為設(shè)計即按照一種思路或者標(biāo)準(zhǔn)來實現(xiàn)功能結(jié)合設(shè)計哲學(xué)小即是美讓每個程序只做好一件事快速建立原型舍棄高效率而取可移植性采用純文本來存儲數(shù)據(jù)充分利用軟件的杠桿效應(yīng)復(fù)用,抽象使用腳本來提高杠桿效應(yīng)和可移植性避免強制性的用戶界面允許用戶定制環(huán)境盡量 何為設(shè)計 即按照一種思路或者標(biāo)準(zhǔn)來實現(xiàn)功能 結(jié)合《UNIX/LINUX設(shè)計哲學(xué) 小即是美 讓每個程序只做好一件事 快速建立原型 舍棄高效率而取可...
摘要:事件系統(tǒng)合成事件的綁定方式合成事件的實現(xiàn)機制事件委派和自動綁定。高階組件如果已經(jīng)理解高階函數(shù),那么理解高階組件也很容易的。例如我們常見的方法等都是高階函數(shù)。對測試群眾來說,從質(zhì)量保證的角度出發(fā),單元測試覆蓋率是 事件系統(tǒng) 合成事件的綁定方式 `Test` 合成事件的實現(xiàn)機制:事件委派和自動綁定。 React合成事件系統(tǒng)的委托機制,在合成事件內(nèi)部僅僅是對最外層的容器進(jìn)行了綁定,并且依賴...
摘要:原型鏈只看構(gòu)造函數(shù)的原型對象和實例化出來的對象。既然構(gòu)造函數(shù)本身是函數(shù),那么和直接調(diào)用有什么區(qū)別答案揭曉只有通過調(diào)用構(gòu)造函數(shù)才會走第二步,也就是原型的委托操作。 原型 相信js開發(fā)者都知道原型,原型鏈,但是很多人暈暈乎乎對此不知甚解。下面分享一下我的個人心得。 學(xué)習(xí)中的困惑 構(gòu)造函數(shù),原型,實例對象之間的關(guān)系是什么? 原型鏈?zhǔn)窃趺蠢^承的? 既然構(gòu)造函數(shù)本身是函數(shù),那么new和直接調(diào)用...
閱讀 2169·2021-10-08 10:15
閱讀 1197·2019-08-30 15:52
閱讀 524·2019-08-30 12:54
閱讀 1542·2019-08-29 15:10
閱讀 2695·2019-08-29 12:44
閱讀 3017·2019-08-29 12:28
閱讀 3365·2019-08-27 10:57
閱讀 2224·2019-08-26 12:24