更新時間:2024-07-28 20:44:06作者:佚名
干燥
這里的DRY是Do Not Repeat Yourself的縮寫,詳細解釋可以參考Every piece of knowledge must have a single, unambiguous, authority at a system這個嚴謹的定義,也就是說任何知識在系統內都必須只有一個單一的、明確的、權威的表述。???這是什么意思?沒看懂。簡單來說就是不要重復你工作的任何一部分。比如有一段代碼是用來清除字符串中的HTML符號的,這個函數會在多個程序中用到,如果在每一處都用到下面的代碼
html = html.replaceAll("\<.*?>","") html = html.replaceAll(" ",""); html = html.replaceAll("&"."");
如果只是在 2、3 處用到(Martin 曾經提到過 Rule of three,意思是如果一段代碼被復制了 3 次以上,就應該重構為單獨的子方法)authoritative是什么意思,你可能直接復制過來用就行,但是想想看,如果在 2、3 百處用到會怎么樣?如果上面又需要修改(如下圖)網校頭條,你是不是也要在這 2、3 百處修改代碼呢?
html = html.replaceAll("<"."<"); html = html.replaceAll(">".">");
因此,DRY 規則建議使用子方法,這樣您只需修改一次。類似的編程思想包括 DIE(Duplication is Evil)、SPoT(Single Point of Truth)、SSOT(Singel Source of Truth)。順便說一句,DRY 的對應詞是 WET,意思是“把所有東西都寫兩遍”或“我們喜歡打字”。:-)。
吻
KISS 是 Keep it simple, stupid(或 Keep it short and simple)的縮寫,意思是保持設計簡潔、通俗,這跟現在流行的“極簡主義風格”很像。
使用 KISS 有什么好處?以下是其中一些:
在軟件設計領域,有一些技術實現了這個本質,比如 DDD(領域驅動設計)和 TDD(測試驅動開發),將代碼集中在真正需要的功能上,不做任何額外的工作。另一個建議是不要試圖通過注釋來提高代碼的可讀性,而是從代碼本身開始改進。例如,下面是一個不太好的變量定義
// i is for 'counter' and j means total sum int i, j;
以下是一個好的設計
// more intuitive oneint counter,sum;
與此相呼應的是奧卡姆剃刀原理或簡單定律:
奧卡姆剃刀
最簡單的(解釋|解決方案)通常是最好的。
通常最簡單的解決方案就是最好的解決方案
具體對于 Java 編程,這里有一些練習 KISS 的建議:
新澤西風格(越差越好)
新澤西風格,又稱“更糟糕的是更好的”。該原則指出,系統的質量不會隨著新功能的增加而提高。例如,一個只提供少量功能但用戶容易使用的軟件可能比一些提供大量令人眼花繚亂功能的“大雜燴”軟件更好。例如Linux下的vi/vim,瀏覽器中的Chrome。
堅硬的
SOLID 是幾種編程哲學的統稱,即 SOLID(單一職責,開放封閉,里氏替換,接口隔離和依賴倒置)。我們來一一解釋一下:
單一職責(SRP)
單一職責原則。Robert 將其描述為“一個類應該只有一個改變的理由”,即有(且只能有)一個理由來修改一個類(或模塊)。簡單地說,一個類或模塊只能負責一個功能。例如,有一個模塊負責生成報告。可以想象,修改這個模塊可能有兩個理由,一是需要改變報告的內容,二是需要改變報告的格式。這兩個改變是由于不同的原因,一個是為了美化內容的布局。“單一職責”規則認為authoritative是什么意思,這是兩個不同的職責,所以應該分成兩個不同的子模塊。如果把兩個東西放在一起,不同的改變是由于不同的原因,這種設計就不好。這個規則有利于系統中模塊的解耦。
開放/封閉原則(OCP)
開放-封閉原則。Bertrand 將其描述為“軟件實體(類、模塊、函數等)應該對擴展開放,但對修改封閉”,這意味著對于一個實體(類、模塊、方法等)來說,它的功能行為允許在不修改源代碼的情況下進行擴展。換句話說,你可以把新代碼放入一個新的類或方法中,而新類通過繼承重用現有的代碼和函數。只有在修復 bug 時才會修改現有的代碼。這個原則主要用于減少添加新功能時引入新 bug 的風險。
里氏替換原則 (LSP)
里氏替換原則。原文是“派生類必須可替換其基類。”,意思是派生類(子類)對象可以用來替換其基類(超類)對象。比如說,假設S是T的子類,那么T類的任何一個具體實現對象都可以替換掉S的實現對象出現的地方,而具體調用者并不知道是父類還是子類,也不會出現錯誤。比如下圖中,調用者可以將1替換成2。
接口隔離原則(ISP)
接口隔離。原文是多個客戶端專用接口優于一個通用接口。意思是多個專用的客戶端接口比一個用途廣泛的接口要好。將接口做細粒度,使之專用于客戶端。應該定義一系列粒度合適的接口(如下圖所示),讓每個客戶都能實現特定的功能請求。換句話說,客戶端不應該依賴于它不使用的功能方法。這個原則的目的是將系統解耦,以便于重構、更改和重新部署。
依賴倒置原則 (DIP)
依賴倒置原則。原文是“Depend upon Abstractions. Do not depend upon concretions”。意思是方法應該遵循“依賴于抽象,而不是依賴于實例”。這個原則規定:
高級模塊不應該依賴于低級模塊,兩者都應該依賴于抽象接口。
抽象接口不應該依賴于具體實現。具體實現應該依賴于抽象接口。
這個很像設計模式里的Adaptor模式。
下圖解釋了這一原理。
圖1中,高級對象A依賴于底層對象B的實現;圖2中,高級對象A對底層對象的需求被抽象成一個接口A,底層對象B實現了接口A,這就是依賴反轉。
系統性紅斑
關注點分離是處理復雜性的一個原則。由于關注點混合在一起會大大增加復雜性,因此能夠將不同的關注點分離并分別處理是處理復雜性的一個原則和方法。這和 SOLID 中的 SRP 非常相似。
楊吉
它是“You aren't gonna need it”的縮寫,字面意思是“你以后不會需要它”。這是極限編程中的一個編程思想。意思是你永遠不要因為預期會用到某個功能就去寫一段代碼來實現它。只有當出現問題并且你確實需要這個功能時,你才應該寫它。