程序設計原則（轉載）

一、結構化程序設計的主要原則

1、自頂向下

　　程序設計時，應先考慮總體，後考慮細節；先考慮全局目標，後考慮局部目標。不要一開始就過多追求衆多的細節，先從最上層總目標開始設計，逐步使問題具體化。

2、逐步求精

　　對複雜問題，應設計一些子目標作爲過渡，逐步細化。

3、模塊化

　　一個複雜問題，肯定是由若干稍簡單的問題構成。模塊化是把程序要解決的總目標分解爲子目標，再進一步分解爲具體的小目標，把每一個小目標稱爲一個模塊。

4、限制使用goto語句

　　結構化程序設計方法的起源來自對GOTO語句的認識和爭論。肯定的結論是：在塊和進程的非正常出口處往往需要用GOTO語句，使用GOTO語句會使程序執行效率較高；在合成程序目標時，GOTO語句往往是有用的，如返回語句用GOTO。否定的結論是：GOTO語句是有害的，是造成程序混亂的禍根，程序的質量與GOTO語句的數量呈反比，應該在所有高級程序設計語言中取消GOTO語句。取消GOTO語句後，程序易於理解、易於排錯、容易維護，容易進行正確性證明。作爲爭論的結論，1974年Knuth發表了令人信服的總結，並證實了：

• GOTO語句確實有害，應當儘量避免；
• 完全避免使用GOTO語句也並非是個明智的方法，有些地方使用GOTO語句，會使程序流程更清楚、效率更高。
• 爭論的焦點不應放在是否取消GOTO語句上，而應放在用什麼樣的程序結構上。其中最關鍵的是，應在以提高程序清晰性爲目標的結構化方法中限制使用GOTO語句；

二、面向對象程序設計的主要原則

1、單一職責原則(Single-Responsibility Principle)　　

　　就一個類而言，應該只專注於做一件事和僅有一個引起它變化的原因。所謂職責，我們可以理解爲功能，就是設計的這個類功能應該只有一個，而不是兩個或更多。也可以理解爲引用變化的原因，當你發現有兩個變化會要求我們修改這個類，那麼你就要考慮撤分這個類了。因爲職責是變化的一個軸線，當需求變化時，該變化會反映類的職責的變化。

　　優點：消除耦合，減小因需求變化引起代碼僵化。

2、里氏代換原則(Liskov Substitution Principle)

　　子類型必須能夠替換它們的基類型。一個軟件實體如果使用的是一個基類，那麼當把這個基類替換成繼承該基類的子類，程序的行爲不會發生任何變化。軟件實體察覺不出基類對象和子類對象的區別。

　　優點：可以很容易的實現同一父類下各個子類的互換，而客戶端可以毫不察覺。

3、依賴倒置原則(Dependence Inversion Principle)

　　要依賴於抽象，不要依賴於具體，客戶端依賴於抽象耦合；抽象不應依賴於細節，細節應依賴於抽象；要針對接口編程，不針對實現編程。

　　優點：使用傳統過程化程序設計所創建的依賴關係，策略依賴於細節，這是糟糕的，因爲策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴於抽象，抽象的穩定性決定了系統的穩定性。

　　怎樣做到依賴倒置？

• 以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關係總要涉及具體類從抽象類繼承，並且需要保證在任何引用到基類的地方都可以改換成其子類，因此，里氏代換原則是依賴倒轉原則的基礎。
• 在抽象層次上的耦合雖然有靈活性，但也帶來了額外的複雜性，如果一個具體類發生變化的可能性非常小，那麼抽象耦合能發揮的好處便十分有限，這時可以用具體耦合反而會更好。

　　層次化：所有結構良好的面向對象構架都具有清晰的層次定義，每個層次通過一個定義良好的、受控的接口向外提供一組內聚的服務。

　　依賴於抽象：建議不依賴於具體類，即程序中所有的依賴關係都應該終止於抽象類或者接口。儘量做到：

• 任何變量都不應該持有一個指向具體類的指針或者引用；
• 任何類都不應該從具體類派生；
• 任何方法都不應該覆寫它的任何基類中的已經實現的方法；

4、接口隔離原則(Interface Segregation Principle)

　　使用多個專一功能的接口比使用一個的總接口總要好。從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小接口上的。過於臃腫的接口是對接口的污染，不應該強迫客戶依賴於它們不用的方法。

　　優點：會使一個軟件系統功能擴展時，修改的壓力不會傳到別的對象那裏。

　　如何實現接口隔離原則？

• 利用委託分離接口；
• 利用多繼承分離接口；

5、迪米特原則(Law of Demeter)

　　迪米特法則又叫做最少知識原則(Least Knowledge Principle或簡寫爲LKP)，就是說，一個對象應當對其他對象有儘可能少的瞭解，對象與對象之間應使用盡可能少的方法來關聯，避免千絲萬縷的關係。

　　在軟件系統中，一個模塊設計的好不好的最主要、最重要的標誌，就是該模塊在多大的程度上將自己的內部數據和其他與實現有關的細節隱藏起來。一個設計好的模塊可以將它所有的實現細節隱藏起來，徹底地將提供給外界的API和自己的實現分割開來。這樣一來，模塊與模塊之間就可以僅僅通過彼此的API相互通信，而不理會模塊內部的工作細節。這一概念就是“信息的隱藏”，或叫做“封裝”，也就是大家熟悉的軟件設計的基本教義之一。信息的隱藏非常重要的原因在於，它可以使各個子系統之間脫藕，從而允許它們獨立地被開發、優化、使用、閱讀以及修改。

　　如何實現迪米特法則？

　　迪米特法則的主要用意是控制信息的過載，在將其運用到系統設計中應注意以下幾點：

• 在類的劃分上，應當創建有弱耦合的類，類之間的耦合越弱，就越有利於複用
• 在類的結構設計上，每一個類都應當儘量降低成員的訪問權限。一個類不應當public自己的屬性，而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。
• 在類的設計上，只要有可能，一個類應當設計成不變類
• 在對其它對象的引用上，一個類對其它對象的引用應該降到最低
• 對於頂級的類來說，只有兩個可能的訪問性等級：package-private和public，一個類可以設置成爲package-private的，就不應該把它設置成爲public的
• 謹慎使用Serializable：如果一個類實現了Serializable接口的話，客戶端就可以將這個類串行後再並行化。假如以後這個類一旦修改，客戶端勢必也將改動。所以能不用就不用

6、開放－封閉原則(Open-Closed Principle)

　　對擴展開放，對修改關閉。

　　優點：按照OCP原則設計出來的系統，降低了程序各部分之間的耦合性，其適應性、靈活性、穩定性都比較好。當已有軟件系統需要增加新的功能時，不需要對作爲系統基礎的抽象層進行修改，只需要在原有基礎上附加新的模塊就能實現所需要添加的功能。增加的新模塊對原有的模塊完全沒有影響或影響很小，這樣就無須爲原有模塊進行重新測試。

　　如何實現“開-閉”原則？

• 在面向對象設計中，不允許更改的是系統的抽象層，而允許擴展的是系統的實現層。
• 解決問題關鍵在於抽象化，抽象化是面向對象設計的第一個核心本質。對一個事物抽象化，即封裝了事物的本質，看不到任何細節。
• 在面向對象編程中，通過抽象類及接口，規定了具體類的特徵作爲抽象層，相對穩定，不需更改，從而滿足“對修改關閉”；而從抽象類導出的具體類可以改變系統的行爲，從而滿足“對擴展開放”。
• 對實體進行擴展時，不必改動軟件的源代碼或者二進制代碼。

三、優秀程序設計的18大原則

1、避免重複原則(DRY - Don’t repeat yourself)

　　編程的最基本原則是避免重複。在程序代碼中總會有很多結構體，如循環、函數、類等等。一旦你重複某個語句或概念，就很容易形成一個抽象體。

2、抽象原則(Abstraction Principle)

　　與DRY原則相關。要記住，程序代碼中每一個重要的功能，只能出現在源代碼的一個位置。

3、簡單原則(Keep It Simple and Stupid)

　　簡單是軟件設計的目標，簡單的代碼佔用時間少，漏洞少，並且易於修改。

4、避免創建你不要的代碼(Avoid Creating a YAGNI (You aren’t going to need it))

　　除非你需要它，否則別創建新功能。

5、儘可能做可運行的最簡單的事(Do the simplest thing that could possibly work)

　　儘可能做可運行的最簡單的事。在編程中，一定要保持簡單原則。作爲一名程序員不斷的反思“如何在工作中做到簡化呢?”這將有助於在設計中保持簡單的路徑。

6、別讓我思考(Don’t make me think)

　　這是Steve Krug一本書的標題，同時也和編程有關。所編寫的代碼一定要易於讀易於理解，這樣別人纔會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程序，其他人總是會避而遠之的。

7、開閉原則(Open/Closed Principle)

　　你所編寫的軟件實體(類、模塊、函數等)最好是開源的，這樣別人可以拓展開發。不過，對於你的代碼，得限定別人不得修改。換句話說，別人可以基於你的代碼進行拓展編寫，但卻不能修改你的代碼。

8、代碼維護(Write Code for the Maintainer)

　　一個優秀的代碼，應當使本人或是他人在將來都能夠對它繼續編寫或維護。代碼維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的代碼要儘可能保證他人能夠容易維護。用書中原話說“如果一個維護者不再繼續維護你的代碼，很可能他就有想殺了你的衝動。”

9、最小驚訝原則(Principle of least astonishment)

　　最小驚訝原則通常是在用戶界面方面引用，但同樣適用於編寫的代碼。代碼應該儘可能減少讓讀者驚喜。也就是說，你編寫的代碼只需按照項目的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。

10、單一責任原則(Single Responsibility Principle)

　　某個代碼的功能，應該保證只有單一的明確的執行任務。

11、低耦合原則(Minimize Coupling)

　　代碼的任何一個部分應該減少對其他區域代碼的依賴關係。儘量不要使用共享參數。低耦合往往是完美結構系統和優秀設計的標誌。

12、最大限度凝聚原則(Maximize Cohesion)

　　相似的功能代碼應儘量放在一個部分。

13、隱藏實現細節(Hide Implementation Details)

　　隱藏實現細節原則，當其他功能部分發生變化時，能夠儘可能降低對其他組件的影響。

14、迪米特法則又叫作最少知識原則(Law of Demeter)

　　該代碼只和與其有直接關係的部分連接。(比如：該部分繼承的類，包含的對象，參數傳遞的對象等)。

15、避免過早優化(Avoid Premature Optimization)

　　除非你的代碼運行的比你想像中的要慢，否則別去優化。假如你真的想優化，就必須先想好如何用數據證明，它的速度變快了。

　　“過早的優化是一切罪惡的根源”——Donald Knuth

16、代碼重用原則(Code Reuse is Good)

　　重用代碼能提高代碼的可讀性，縮短開發時間。

17、關注點分離(Separation of Concerns)

　　不同領域的功能，應該由不同的代碼和最小重迭的模塊組成。

18、擁抱改變(Embrace Change)

　　這是Kent Beck一本書的標題，同時也被認爲是極限編程和敏捷方法的宗旨。

參考鏈接：

　　http://blog.csdn.net/coolingcoding/article/details/8043265

　　http://blog.csdn.net/xyylchq/article/details/6291925

　　http://jingyan.baidu.com/article/75ab0bcbfb2670d6864db219.html