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
具体内容:
如何医治：