最近在审查(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) 很难被重用.
还有一些原则可能被遗漏掉,如果你发现了,请及时提醒我.