国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

漫談開發設計中的一些“原則”及“設計哲學”

william / 1705人閱讀

摘要:在開發設計中有一些常用原則或者潛規則,根據筆者的經驗,這里稍微總結一下最最常用的,以饗讀者。是處理復雜性的一個原則。參考六大設計原則里氏替換原則奧卡姆剃刀如有問題可以通過郵件微信聯系我。

在開發設計中有一些常用原則或者潛規則,根據筆者的經驗,這里稍微總結一下最最常用的,以饗讀者。

DRY

這里的DRY是Do Not Repeat Yourself的縮寫。具體解釋參見 ,嚴謹的定義是 Every piece of knowledge must have a single, unambiguous, authoritative representation within a system,意思是:任何一部分知識在系統中必須只有單一的,清晰并且權威的展示。???這是啥意思,沒懂。簡單說就是不要重復自己任何一部分的工作。比如說,有一段代碼是用于清除字條串中的HTML符號,在多個程序中會用到此功能,如果每個地方都使用如下代碼

html = html.replaceAll("<.*?>","") 
html = html.replaceAll("?","");
html = html.replaceAll("&"."");

如果是只有2,3個地方用到(Martin曾經提到過Rule of three,意思是一段代碼如果被copy3次以上就應該重構到一個多帶帶的子方法中),你可能就直接復制過來用,但是想想是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,意思是 "write everything twice"(任何東西都寫兩遍)或者"we enjoy typing" (我們就是喜歡打字編碼)。 :-)

KISS

KISS 是 Keep it simple, stupid (或者Keep it short and simple )的簡稱。意思是在設計時保持簡約,通俗。這個很像是現在推暢的“極簡風”。

使用KISS有什么好處呢?如下是其中的一些:

你可以更快的解決更多的問題

你可以使用更少的代碼來解決復雜的問題

你可以寫出更高質量的代碼

你可以創建更大的系統,更好的去運維

你的代碼將更加靈活,當有新需求時可以更好的支持擴展,修改或者重構

等等

在軟件設計領域, 有一些技術具體實現這個精髓,比如 DDD (Domain Driven Design),TDD (Test Driven Develop),這個使代碼集中在真正需要的功能上,而不需要其他額外的。另外一個建議是 不要試圖通過注釋來提高代碼的可讀性,而應該從代碼本身提高。比如如下是不太好的變量定義

// i is for "counter" and j means total sum
int i, j;

而如下是好的設計

// more intuitive one
int counter,sum;

與此相呼應的是稱作 奧卡姆剃刀 或者 簡約之法則

Occam"s razor
The simplest (explanation|solution) is usually the best one.
往往最簡單的解決方案是最好的解決方案

具體到以Java為例的程序設計,如下有一些實踐KISS的建議

首先,認清自己,不要認為自己是個天才,這往往是你犯的第一個錯。

把你的工作打散成幾個子工作,每個部分不會耗費超過4-12個小時去完成

把一個問題分成幾個小的子問題,每個問題可以通過1個或者只要幾個類就能解決。

保持每個方法只做一件事,并且不要超過30-40行的代碼量

保持每個類的體積不要太大。

不要害怕扔掉不用的代碼。就像家里用不到的東西就及時扔掉一樣。

New Jersey style (Worse is better)

新澤西風格,也叫做“Worse is better”。此原則指出,系統的質量不會因為新功能的增多而提高。 比如一個軟件,只提供一些功能,但是用戶很方便使用,有可能比一些提供了非常多令人眼花繚亂功能的“大雜燴”似的軟件。比如像 Linux下面的 vi/vim, 瀏覽器中的Chrome.

SOLID

SOLID是幾個編程哲學的總稱,即 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.”,即修改一個類(或者模塊)有(且只能有)一個理由。簡單說就是 一個類或者模塊只能負責一個功能。舉個例子,有一個模塊負責生成一個報表,可以想像可能有兩個理由去修改此模塊,第一,報表的內容要變,第二,報表的格式要改。這兩個改動是出于不同的理由,一個是內容的一個美化版面的。 而 “單一職責” 規則認為這是兩個不同的職責,因此應該分成兩個不同的子模塊。如果把兩件事情放在一起,并且不同的改動是出于不同的原因,這種設計是不好的。此規則方便系統各模塊間解耦合。

Open/closed principle (OCP)

開閉原則。Bertrand描述為“"software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";”,也就是說對于一個實體(類,模塊,方法等)允許在不修改源代碼的前提下擴展它的功能行為。即,你可以把 新代碼放到新的類或者方法中,新類通過繼承來重用已有代碼及功能。而 已有的代碼只有在修bug時才去修改。 此原則主要用于降低在添加新加功能時引入新的bug的風險。

The Liskov Substitution Principle (LSP)

里氏替換原則. 原文是 “Derived classes must be substitutable for their base classes.”,意思是,派生類(子類)對象能夠替換其基類(超類)對象被使用。 比如說,如果 S 是T 的子類, 那么任何T類的具體實現對象都可以替換S的實現對象出現的地方,具體的調用者也不知道具體是父類還是子類,還不會出現任何錯誤。比如下圖,調用者可以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. 應該定義粒度合適的一系列接口(像下圖),以便于每個客戶去實現具體的功能請求。換句話說是,客戶(client)不應該必須去依賴于它用不到的功能方法。此原則的目的是系統解開耦合,從而容易重構,更改和重新部署。

Dependency inversion principle (DIP)

依賴反轉原則. 原文是 One should “Depend upon Abstractions. Do not depend upon concretions.” 意思是 一個方法應該遵從“依賴于抽象而不是一個實例”。該原則規定:

高層次的模塊不應該依賴于低層次的模塊,兩者都應該依賴于抽象接口。

抽象接口不應該依賴于具體實現。而具體實現則應該依賴于抽象接口。

這個就像是設計模式中的Adaptor適配器模式。下圖解釋了這個原理。

圖1中,高層對象A依賴于底層對象B的實現;圖2中,把高層對象A對底層對象的需求抽象為一個接口A,底層對象B實現了接口A,這就是依賴反轉。

SOC

Separation of concerns,?即關注點分離。 是處理復雜性的一個原則。由于關注點混雜在一起會導致復雜性大大增加,所以能夠把不同的關注點分離開來,分別處理就是處理復雜性的一個原則,一種方法。這個與SOLID中的 SRP很類似。

YANGI

是"You aren"t gonna need it"的縮寫,直譯是“你將來用不到它的”。這個是極限編程的一個編程思想。意思是說,永遠不要因為 預計你會用到某個功能就去寫一段代碼去實現,總是只有問題出現了,真的需要這個功能時才去寫

參考

DRY

六大設計原則--里氏替換原則【Liskov Substitution Principle】

SOLID)

how to keep code simple

奧卡姆剃刀

Apache KISS

Worse is better

如有問題可以通過郵件phray@163.com/微信helloworld_2000聯系我。謝謝。
原文位于: http://cloudsdocker.github.io...

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/65122.html

相關文章

  • 設計原則

    摘要:何為設計設計哲學中講到的一些設計準則設計準則小即是美讓每個程序只做好一件事快速建立原型先滿足基本需求,再后續升級舍棄高效率而采取可移植性采用純文本來存儲數據可讀性好充分利用軟件的杠桿效應軟件復用使用腳本來提高杠桿效應和可移植性避免強制性的用 何為設計 《Unix/Linux設計哲學》中講到的一些設計準則: 設計準則 小即是美 讓每個程序只做好一件事 快速建立原型(先滿足基本需求,再后...

    DirtyMind 評論0 收藏0
  • 金幣(積分)商城架構漫談

    摘要:開篇金幣積分商城下稱商城是眾多內的一個產品,隨著使用的用戶越來越多,商城對于用戶留存的提升,扮演著重要的角色做為提高用戶黏性的核心產品,在擁有很好用戶體驗的同時,也必須存在著一個高效穩定的系統。分析上述兩點,得到結論按用戶進行分庫分表。 開篇 金幣(積分)商城(下稱商城)是眾多App內的一個產品,隨著App使用的用戶越來越多,商城對于用戶留存的提升,扮演著重要的角色;做為提高用戶黏性的...

    Ethan815 評論0 收藏0
  • JavaScript設計模式(一)設計原則

    摘要:何為設計即按照一種思路或者標準來實現功能結合設計哲學小即是美讓每個程序只做好一件事快速建立原型舍棄高效率而取可移植性采用純文本來存儲數據充分利用軟件的杠桿效應復用,抽象使用腳本來提高杠桿效應和可移植性避免強制性的用戶界面允許用戶定制環境盡量 何為設計 即按照一種思路或者標準來實現功能 結合《UNIX/LINUX設計哲學 小即是美 讓每個程序只做好一件事 快速建立原型 舍棄高效率而取可...

    Reducto 評論0 收藏0
  • React學習之漫談React

    摘要:事件系統合成事件的綁定方式合成事件的實現機制事件委派和自動綁定。高階組件如果已經理解高階函數,那么理解高階組件也很容易的。例如我們常見的方法等都是高階函數。對測試群眾來說,從質量保證的角度出發,單元測試覆蓋率是 事件系統 合成事件的綁定方式 `Test` 合成事件的實現機制:事件委派和自動綁定。 React合成事件系統的委托機制,在合成事件內部僅僅是對最外層的容器進行了綁定,并且依賴...

    darkbug 評論0 收藏0
  • 漫談js-原型

    摘要:原型鏈只看構造函數的原型對象和實例化出來的對象。既然構造函數本身是函數,那么和直接調用有什么區別答案揭曉只有通過調用構造函數才會走第二步,也就是原型的委托操作。 原型 相信js開發者都知道原型,原型鏈,但是很多人暈暈乎乎對此不知甚解。下面分享一下我的個人心得。 學習中的困惑 構造函數,原型,實例對象之間的關系是什么? 原型鏈是怎么繼承的? 既然構造函數本身是函數,那么new和直接調用...

    shuibo 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<