良好的編程原則與良好的設(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è)計的目標，簡單的代碼占用時間少，漏洞少，并且易于修改。
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一本書的標題，同時也和編程有關(guān)。所編寫的代碼一定要易于讀易于理解，這樣別人才會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程序，其他人總是會避而遠之的。
7.開閉原則(Open/Closed Principle)
你所編寫的軟件實體（類、模塊、函數(shù)等）最好是開源的，這樣別人可以拓展開發(fā)。不過，對于你的代碼，得限定別人不得修改。換句話說，別人可以基于你的代碼進行拓展編寫，但卻不能修改你的代碼。
8.代碼維護(Write Code for the Maintainer)
一個優(yōu)秀的代碼，應(yīng)當使本人或是他人在將來都能夠?qū)λ^續(xù)編寫或維護。代碼維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的代碼要盡可能保證他人能夠容易維護。用書中原話說“如果一個維護者不再繼續(xù)維護你的代碼，很可能他就有想殺了你的沖動。”
9.最小驚訝原則(Principle of least astonishment)
最小驚訝原則通常是在用戶界面方面引用，但同樣適用于編寫的代碼。代碼應(yīng)該盡可能減少讓讀者驚喜。也就是說，你編寫的代碼只需按照項目的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。
10.單一責任原則(Single Responsibility Principle)
某個代碼的功能，應(yīng)該保證只有單一的明確的執(zhí)行任務(wù)。
11.低耦合原則(Minimize Coupling)
代碼的任何一個部分應(yīng)該減少對其他區(qū)域代碼的依賴關(guān)系。盡量不要使用共享參數(shù)。低耦合往往是完美結(jié)構(gòu)系統(tǒng)和優(yōu)秀設(shè)計的標志。
12.最大限度凝聚原則(Maximize Cohesion)
相似的功能代碼應(yīng)盡量放在一個部分。
13.隱藏實現(xiàn)細節(jié)（Hide Implementation Details）
隱藏實現(xiàn)細節(jié)原則，當其他功能部分發(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一本書的標題，同時也被認為是極限編程和敏捷方法的宗旨。
許多其他原則都是基于這個概念的，即你應(yīng)該積極面對變化。事實上，一些較老的編程原則如最小化耦合原則都是為了使代碼能夠容易變化。無論你是否是個極限編程者，基于這個原則去編寫代碼會讓你的工作變得更有意義。
作者簡介：Christopher Diggins是加拿大一位有25年編程經(jīng)驗的資深技術(shù)人員，曾效力于Microsoft和AutoDesk，并創(chuàng)辦過兩家贏利的互聯(lián)網(wǎng)公司。
他是《C++ Cookbook》的作者之一，并自己編寫了一門編程語言Heron。
今天見識了手機的NFC（近場感應(yīng)技術(shù)）功能，確實給生活帶來了很大方便?？梢韵胂?，以后的門、窗、電腦、電視、空調(diào)、汽車……不久以后的商場甚至是taxi…… 只有想不到的，沒有用不到的。這技術(shù)也許并不新奇，但是手機的功能正在向更強、更新、更快發(fā)展，似乎所有的功能我們都想把它給予手機……也許以后手機就是披著手機外衣的“萬事通”。
多態(tài)，解釋為接口的多種不同實現(xiàn)方式式，但是并不是聲明為interface的接口類才能使用，不要被他迷惑了，我們就把它當成一個抽象類，一個“稍微”特殊的類，用類的使用方法來使用它。
首先，抽象類中沒有構(gòu)造方法，所以我們不能直接聲明它的對象，也就不能通過對象調(diào)用方法，但是它有至少一個子類，這就為我們留了一扇門。只要我們知道某個對象屬于它的子類（不必去知道究竟那個子類），我們就可以通過子類的對象調(diào)用方法。那么，究竟怎么知道那到底屬于那個子類呢？這就靠不同子類對抽象父類中這個方法的不同重寫來完成。那么，這句話是不是有點熟悉？對！ 方法的重載跟這何其相似，不同的在于其“級別”不同：一個是自主判斷所屬子類而調(diào)用方法，一個是自主判斷不同參數(shù)調(diào)用方法。
其次，就是對方法的調(diào)用了。當父類指向子類，例如 Student stu = new littleStudent(); littleStudent 是抽象類Student的子類并且對Student的至少一個方法進行了重寫。那么當我使用stu調(diào)用方法時，對于父類中有但是子類沒有重寫的方法，stu自動調(diào)用父類中的方法；而對于在子類中有重寫的方法，stu調(diào)用子類中的方法。