良好的編程原則與良好的設(shè)計工程原則密切相關(guān)。本文總結(jié)的這些設(shè)計原則,幫助開發(fā)者更有效率的編寫代碼,并幫助成為一名優(yōu)秀的程序員。
1.避免重復(fù)原則(DRY – Don’t repeat yourself)
編程的最基本原則是避免重復(fù)。在程序代碼中總會有很多結(jié)構(gòu)體,如循環(huán)、函數(shù)、類等等。一旦你重復(fù)某個語句或概念,就會很容易形成一個抽象體。
2.抽象原則(Abstraction Principle )
與DRY原則相關(guān)。要記住,程序代碼中每一個重要的功能,只能出現(xiàn)在源代碼的一個位置。
3.簡單原則(Keep It Simple and Stupid )
簡單是軟件設(shè)計的目標(biāo),簡單的代碼占用時間少,漏洞少,并且易于修改。
4.避免創(chuàng)建你不要的代碼 Avoid Creating a YAGNI (You aren’t going to need it)
除非你需要它,否則別創(chuàng)建新功能。
5.盡可能做可運行的最簡單的事(Do the simplest thing that could possibly work)
盡可能做可運行的最簡單的事。在編程中,一定要保持簡單原則。作為一名程序員不斷的反思“如何在工作中做到簡化呢?”這將有助于在設(shè)計中保持簡單的路徑。
6.別讓我思考(Don’t make me think )
這是Steve Krug一本書的標(biāo)題,同時也和編程有關(guān)。所編寫的代碼一定要易于讀易于理解,這樣別人才會欣賞,也能夠給你提出合理化的建議。相反,若是繁雜難解的程序,其他人總是會避而遠之的。
7.開閉原則(Open/Closed Principle)
你所編寫的軟件實體(類、模塊、函數(shù)等)最好是開源的,這樣別人可以拓展開發(fā)。不過,對于你的代碼,得限定別人不得修改。換句話說,別人可以基于你的代碼進行拓展編寫,但卻不能修改你的代碼。
8.代碼維護(Write Code for the Maintainer)
一個優(yōu)秀的代碼,應(yīng)當(dāng)使本人或是他人在將來都能夠?qū)λ^續(xù)編寫或維護。代碼維護時,或許本人會比較容易,但對他人卻比較麻煩。因此你寫的代碼要盡可能保證他人能夠容易維護。用書中原話說“如果一個維護者不再繼續(xù)維護你的代碼,很可能他就有想殺了你的沖動。”
9.最小驚訝原則(Principle of least astonishment)
最小驚訝原則通常是在用戶界面方面引用,但同樣適用于編寫的代碼。代碼應(yīng)該盡可能減少讓讀者驚喜。也就是說,你編寫的代碼只需按照項目的要求來編寫。其他華麗的功能就不必了,以免弄巧成拙。
10.單一責(zé)任原則(Single Responsibility Principle)
某個代碼的功能,應(yīng)該保證只有單一的明確的執(zhí)行任務(wù)。
11.低耦合原則(Minimize Coupling)
代碼的任何一個部分應(yīng)該減少對其他區(qū)域代碼的依賴關(guān)系。盡量不要使用共享參數(shù)。低耦合往往是完美結(jié)構(gòu)系統(tǒng)和優(yōu)秀設(shè)計的標(biāo)志。
12.最大限度凝聚原則(Maximize Cohesion)
相似的功能代碼應(yīng)盡量放在一個部分。
13.隱藏實現(xiàn)細節(jié)(Hide Implementation Details)
隱藏實現(xiàn)細節(jié)原則,當(dāng)其他功能部分發(fā)生變化時,能夠盡可能降低對其他組件的影響。
14.迪米特法則又叫作最少知識原則(Law of Demeter)
該代碼只和與其有直接關(guān)系的部分連接。(比如:該部分繼承的類,包含的對象,參數(shù)傳遞的對象等)。
15.避免過早優(yōu)化(Avoid Premature Optimization)
除非你的代碼運行的比你想像中的要慢,否則別去優(yōu)化。假如你真的想優(yōu)化,就必須先想好如何用數(shù)據(jù)證明,它的速度變快了。
“過早的優(yōu)化是一切罪惡的根源”——Donald Knuth
16.代碼重用原則(Code Reuse is Good)
重用代碼能提高代碼的可讀性,縮短開發(fā)時間。
17.關(guān)注點分離(Separation of Concerns)
不同領(lǐng)域的功能,應(yīng)該由不同的代碼和最小重迭的模塊組成。
18.擁抱改變(Embrace Change)
這是Kent Beck一本書的標(biāo)題,同時也被認(rèn)為是極限編程和敏捷方法的宗旨。
許多其他原則都是基于這個概念的,即你應(yīng)該積極面對變化。事實上,一些較老的編程原則如最小化耦合原則都是為了使代碼能夠容易變化。無論你是否是個極限編程者,基于這個原則去編寫代碼會讓你的工作變得更有意義。
作者簡介:Christopher Diggins是加拿大一位有25年編程經(jīng)驗的資深技術(shù)人員,曾效力于Microsoft和AutoDesk,并創(chuàng)辦過兩家贏利的互聯(lián)網(wǎng)公司。
他是《C++ Cookbook》的作者之一,并自己編寫了一門編程語言Heron。
Singleton Pattern(單例模式)
改善全局變量和命名空間的沖突,可以說是一種改良了的全局變量。這種一個類只有一個實例,且提供一個訪問全局點的方式,更加靈活的保證了實例的創(chuàng)建和訪問約束。
有時候在使用類的時候,這個類必須存在,但是我們又要求這個類在整個工程中只能有一個對象,無論什么時候調(diào)用都只能調(diào)用這唯一的一個對象,怎么做呢?
這種模式的核心跟javaBean有點類似,不同在于單例模式要求創(chuàng)建并私有化一個對象,同時私有化構(gòu)造方法,重寫構(gòu)造方法使其返回這個對象。為了能夠使用這個對象,我們在其中創(chuàng)建一個靜態(tài)的Get方法用來返回該對象。
一般的我們會用兩種單例模式的方法,一個是延遲加載,又叫懶漢式,另一個是非延遲加載,又稱餓汗式。區(qū)別在于前者是在調(diào)用的時候才生成對象,而后者則是事先生成對象;方法區(qū)別在于是否把生成對象放入get方法(可以加入判斷如果該對象不存在就new一個,存在的話就返回該已存在的對象)。
這種思想在很多地方都會使用,用同樣的思想我們可以解決更多的問題。
23種模式想了解更多的話可以去谷歌看看。我們重點不是掌握幾種方法,而是駕馭這種思想,靈活使用這種方法。高內(nèi)聚,低耦合,在寫程序之前就要對整個過程了解很透徹,而不是邊寫邊想究竟該怎么布局。