最近在審查(review)代碼時,常常發現一大堆代碼充滿了各種bad smell.即使工作了三五年的同事,也不會例外.溝通時往往發現他們對OO的理解只是表現出簡單的概念理解.對OO的一些原則不甚了解,或者寫代碼也是跟著感覺走.
我最初做開發的時候也是跟著感覺走,初次聽到OCP如天外來物.使用Java或C#不代表你就是在做OO開發,熟練使用OO語言不代表已經對OO非常了解.感謝Uncle Bob的經典巨著<Agile Software Development>,堅持閱讀的習慣讓我接觸并努力理解OO原則.一旦對這些原則有了深入的認識,寫代碼時就已經從更高的角度來分析問題,解決問題,力爭寫出優雅的代碼.
我對OO的了解也不算多深刻,只在這里拋磚引玉.因為原則比較多,用一個系列來介紹會讓大家更容易溝通.
同時,原則是死的,人是活的,不要被這些原則束縛,有一些原則在特定的情況下才會有效.
Single Choice Principle(SCP)
所有的判斷只在一處進行.違反此原則的典型情況是不同的方法中充斥著相同的if ... else ...或類似的語句.
Linguistic Modular Units
Few Interfaces
Small Interfaces
Explicit Interfaces
Behavioral Completeness
一個完整的類必須包含完整的方法.如果類沒有完成它的職責,或者沒有完成其父類需要完成的工作,那么它就是不完整的類.
Law Of Demeter
只與直接協作的類交互.
The Principle of Essential Representation(PER)
類應該包含而且只包含其本質的定義和表現,與SRP比較接近.
Single Responsibility Principle(SRP)
一個類只承擔一項職責,只能有一個發生變化的理由,那就是它的職責變化了.
Open-Colse Principle(OCP)
類應該對擴展是開放的,對修改是封閉的.
Liskov Substitution (LSP)
子類必須可以替換父類.
Dependency-Inversion Principles(DIP)
高層應該不依賴于低層,雙方都應該依賴于抽象.抽象不依賴于細節,細節應該依賴于抽象.
Interface Segregation Principles(ISP)
接口屬于客戶程序.
---------------------------------
Reuse Release Equivalence Principle(REP)
重用的粒度等于發布的粒度.
Common Reuse Principle(CRP)
包中的類應該是共同重用的.
Common Closure Principle(CCP)
包中的類對同一類變化共同封閉的,一個類發生變化,可能所有的類都要發生變化.
---------------------------------
Acyclic Dependencies Principle(ADP)
包之間的依賴結構不應該存在環依賴.
Stable Dependencies Principle (SDP)
包應該依賴于比它更穩定的包.
Stable Abstractions Principle(SAP)
包的穩定程度與抽象程度成正比,越抽象的包越穩定.
---------------------------------
開發時應該避免的bad design smell:
僵化(Rigidity) 一處變化會影響系統中的很多地方.
脆弱(Fragility) 一處變化會影響系統中不應該被影響的地方.
牢固(Immobility) 很難被重用.
還有一些原則可能被遺漏掉,如果你發現了,請及時提醒我.