SOLID原則是著名的面向對像設計五原則，之所以要引入這些原則，是為了給以防止程式碼腐化而進行的重構活動定下切實可行的目標。
隨著系統開發的進行，產品程式碼不可避免地會不斷腐化，就算在開發過程中很好地應用了TDD、持續整合等優秀實踐，也無法避免。
腐化的臭味有：
1、僵化-當需求發生變化時，我們要對多個模組進行修改，這主要是在設計層面的問題，因為開發者接到該變更時，就知道有哪些模組要修改了。
2、脆弱-當需求發生變化時，開發者可能知道要改某一個模組，但在修改過程中，他發現由於實現上的原因，改了這個模組後，不得不去修改其它模組，否則整個系統將無法工作。
3、頑固-當開發者發現某一模組中所實現的某一功能也是另一模組所要實現的，但仍然不得不為另一模組重新開發一次，因為要複用之前模組中的程式碼是相當困難的。
4、粘滯-包括開發環境上的原因導致的粘滯，也包括系統設計上的粘滯（開發環境上的粘滯較容易理解，比如按照程式設計規範，修改某一變數需要在一標頭檔案中，但標頭檔案的修改會導致大量原始碼的重新編譯，因而會耗費大量的時間，而如果在原始碼檔案中修改相應的程式碼部份，只需要編譯一個檔案，編譯時間大大縮短，也提高了短時間內的工作效率，但由此埋下的隱患即是當其他人要全量修改相應部份時，會遺漏這個地方。）可以看到開發者知道正確的做法是什麼，可由於某種原因導致他用了不規範的做法，這就是由於環境帶來的粘滯性。
5、不必要的複雜性-這裡主要講設計複雜性，比如為了滿足客戶的某個需求，只需要方案A即可，但開發人員自作聰明覺得也許客戶明天要另一個需求，然後他把方案B也加進去了。也許這真的會中，但從整體來講，這樣做增加了系統設計的複雜性，也許客戶以後根本不會要求增加另一個需求，這樣的設計就是多餘的。
6、不必要的重複-COPY PASTE問題。
7、晦澀-程式碼讓人看不懂，其實程式碼可以寫得通俗易懂，就像小說家寫小說或者散文家寫散文。
這些腐化的臭味有些是設計上的，有些是實現上的，如果任由它們不滿曼延，整個產品將最終變得難以維護且漏洞百出。我全部羅列了出來，其實理解得都不算深刻，還需要在實踐中不斷體會玩味。
這些臭味就像是病人身上表現出來的症狀，醫生很快能識別出來這個人生病了，而且病得不輕。接下來就是要進行診斷並對症下藥了。
如何診斷呢？就是運用SOLID，來看系統到底違反了哪些原則才導致他出現這些病症。
1、單一職責原則 Single Resposibility
具體內容:如果某一需求發生變化，導致類A發生變化，那說明這一需求變化是導致A變化的因素，如果還有另一個需求變化使得A變化，那麼導致A變化的因素就有兩個，這就違返了單一職責原則，這裡的職責應該理解為導致A變化的因素。
如何醫治：將類A進行分離設計，以滿足單一職責原則。
違反單一職責原則將會產生哪些臭味？
2、開閉原則 Open-Close
具體內容:
如何醫治：
3、里氏替換原則 Liskov Substitution
具體內容:
如何醫治：
4、介面隔離原則 Interface Segregation
具體內容:
如何醫治：
5、依賴倒置原則 Dependency-Inversion
具體內容:
如何醫治：