面向對象的S.O.L.I.D 原則
一般來說這是面向對象的五大設計原則，但是，我覺得這些原則可適用於所有的軟件開發。
Single Responsibility Principle (SRP) – 職責單一原則
關於單一職責原則，其核心的思想是：一個類，只做一件事，並把這件事做好，其只有一個引起它變化的原因。單一職責原則可以看作是低耦合、高內聚在面向對象原則上的引申，將職責定義爲引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而極大的損傷其內聚性和耦合度。單一職責，通常意味着單一的功能，因此不要爲一個模塊實現過多的功能點，以保證實體只有一個引起它變化的原因。
- Unix/Linux是這一原則的完美體現者。各個程序都獨立負責一個單一的事。
- Windows是這一原則的反面示例。幾乎所有的程序都交織耦合在一起。
Open/Closed Principle (OCP) – 開閉原則
關於開發封閉原則，其核心的思想是：模塊是可擴展的，而不可修改的。也就是說，對擴展是開放的，而對修改是封閉的。
- 對擴展開放，意味着有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。
- 對修改封閉，意味着類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。
對於面向對象來說，需要你依賴抽象，而不是實現，23個經典設計模式中的“策略模式”就是這個實現。對於非面向對象編程，一些API需要你傳入一個你可以擴展的函數，比如我們的C 語言的qsort()允許你提供一個“比較器”，STL中的容器類的內存分配，ACE中的多線程的各種鎖。對於軟件方面，瀏覽器的各種插件屬於這個原則的實踐。
Liskov substitution principle (LSP) – 里氏代換原則
軟件工程大師Robert C. Martin把里氏代換原則最終簡化爲一句話：“Subtypes must be substitutable for their base types”。也就是，子類必須能夠替換成它們的基類。即：子類應該可以替換任何基類能夠出現的地方，並且經過替換以後，代碼還能正常工作。另外，不應該在代碼中出現if/else之類對子類類型進行判斷的條件。里氏替換原則LSP是使代碼符合開閉原則的一個重要保證。正是由於子類型的可替換性才使得父類型的模塊在無需修改的情況下就可以擴展。
這麼說來，似乎有點教條化，我非常建議大家看看這個原則個兩個最經典的案例——“正方形不是長方形”和“鴕鳥不是鳥”。通過這兩個案例，你會明白《墨子 小取》中說的 ——“娣，美人也，愛娣，非愛美人也….盜，人也；惡盜，非惡人也。”——妹妹雖然是美人，但喜歡妹妹並不代表喜歡美人。盜賊是人，但討厭盜賊也並不代表就討厭人類。這個原則讓你考慮的不是語義上對象的間的關係，而是實際需求的環境。
在很多情況下，在設計初期我們類之間的關係不是很明確，LSP則給了我們一個判斷和設計類之間關係的基準：需不需要繼承，以及怎樣設計繼承關係。
Interface Segregation Principle (ISP) – 接口隔離原則
接口隔離原則意思是把功能實現在接口中，而不是類中，使用多個專門的接口比使用單一的總接口要好。
舉個例子，我們對電腦有不同的使用方式，比如：寫作，通訊，看電影，打遊戲，上網，編程，計算，數據等，如果我們把這些功能都聲明在電腦的抽類裏面，那麼，我們的上網本，PC機，服務器，筆記本的實現類都要實現所有的這些接口，這就顯得太複雜了。所以，我們可以把其這些功能接口隔離開來，比如：工作學習接口，編程開發接口，上網娛樂接口，計算和數據服務接口，這樣，我們的不同功能的電腦就可以有所選擇地繼承這些接口。
這個原則可以提升我們“搭積木式”的軟件開發。對於設計來說，Java中的各種Event Listener和Adapter，對於軟件開發來說，不同的用戶權限有不同的功能，不同的版本有不同的功能，都是這個原則的應用。
Dependency Inversion Principle (DIP) – 依賴倒置原則
高層模塊不應該依賴於低層模塊的實現，而是依賴於高層抽象。
舉個例子，牆面的開關不應該依賴於電燈的開關實現，而是應該依賴於一個抽象的開關的標準接口，這樣，當我們擴展程序的時候，我們的開關同樣可以控制其它不同的燈，甚至不同的電器。也就是說，電燈和其它電器繼承並實現我們的標準開關接口，而我們的開關產商就可不需要關於其要控制什麼樣的設備，只需要關心那個標準的開關標準。這就是依賴倒置原則。
這就好像瀏覽器並不依賴於後面的web服務器，其只依賴於HTTP協議。這個原則實在是太重要了，社會的分工化，標準化都是這個設計原則的體現。