程序設計原則(總結)

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

主要是對像C語言這類結構化的語言，大多采用的就是結構化程序設計。

一、自頂向下

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

二、逐步求精

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

三、模塊化

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

四、限制使用goto語句

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

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

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

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

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

優勢：消除耦合，減少因需求變化引發代碼僵化。

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

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

優勢：能夠很容易的實現同一父類下各個子類的互換，而客戶端能夠絕不察覺。

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

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

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

怎樣作到依賴倒置？

以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關係總要涉及具體類從抽象類繼承，而且須要保證在任何引用到基類的地方均可以改換成其子類，所以，里氏代換原則是依賴倒轉原則的基礎。

在抽象層次上的耦合雖然有靈活性，但也帶來了額外的複雜性，若是一個具體類發生變化的可能性很是小，那麼抽象耦合能發揮的好處便十分有限，這時能夠用具體耦合反而會更好。

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

依賴於抽象：建議不依賴於具體類，即程序中全部的依賴關係都應該終止於抽象類或者接口。儘可能作到：

• 任何變量都不該該持有一個指向具體類的指針或者引用；
• 任何類都不該該從具體類派生；

• 任何方法都不該該覆寫它的任何基類中的已經實現的方法；

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

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

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

如何實現接口隔離原則？

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

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

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

在軟件系統中，一個模塊設計的好很差的最主要、最重要的標誌，就是該模塊在多大的程度上將本身的內部數據和其餘與實現有關的細節隱藏起來。一個設計好的模塊能夠將它全部的實現細節隱藏起來，完全地將提供給外界的API和本身的實現分割開來。這樣一來，模塊與模塊之間就能夠僅僅經過彼此的API相互通訊，而不理會模塊內部的工做細節。這一律念就是「信息的隱藏」，或叫作「封裝」，也就是你們熟悉的軟件設計的基本教義之一。信息的隱藏很是重要的緣由在於，它可使各個子系統之間脫藕，從而容許它們獨立地被開發、優化、使用、閱讀以及修改。

如何實現迪米特法則？

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

• 在類的劃分上，應當建立有弱耦合的類，類之間的耦合越弱，就越有利於複用
• 在類的結構設計上，每個類都應當儘可能下降成員的訪問權限。一個類不該當public本身的屬性，而應當提供取值和賦值的方法讓外界間接訪問本身的屬性。
• 在類的設計上，只要有可能，一個類應當設計成不變類
• 在對其它對象的引用上，一個類對其它對象的引用應該降到最低
• 對於頂級的類來講，只有兩個可能的訪問性等級：package-private和public，一個類能夠設置成爲package-private的，就不該該把它設置成爲public的

• 謹慎使用Serializable：若是一個類實現了Serializable接口的話，客戶端就能夠將這個類串行後再並行化。假如之後這個類一旦修改，客戶端勢必也將改動。因此能不用就不用

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

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

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

如何實現「開-閉」原則？

在面向對象設計中，不容許更改的是系統的抽象層，而容許擴展的是系統的實現層。

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

優秀程序設計的18大原則

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

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

二、抽象原則(Abstraction Principle)

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

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

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

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

除非你須要它，不然別建立新功能。

五、儘量作可運行的最簡單的事(Do the simplest thing that could possibly work)

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

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

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

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

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

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

一個優秀的代碼，應當使本人或是他人在未來都可以對它繼續編寫或維護。代碼維護時，或許本人會比較容易，但對他人卻比較麻煩。所以你寫的代碼要儘量保證他人可以容易維護。用書中原話說「若是一個維護者再也不繼續維護你的代碼，極可能他就有想殺了你的衝動。」

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

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

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

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

十一、低耦合原則(Minimize Coupling)

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

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

類似的功能代碼應儘可能放在一個部分。

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

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

1四、迪米特法則又叫做最少知識原則(Law of Demeter)

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

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

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

「過早的優化是一切罪惡的根源」——Donald Knuth

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

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

1七、關注點分離(Separation of Concerns)

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

1八、擁抱改變(Embrace Change)

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

本文爲轉載文，轉自http://www.cnblogs.com/gaohongchen01/p/4535670.html