软件项目中，需求是不断变化的，需求也是项目中最难把控的，需求的变更也是无法避免的。我们写的软件程序，如何能实现拥抱变化，使我们的软件达到可维护和可复用，这是一代代软件工程师不断追寻的真理。
导致一个软件的可维护性较低的原因有四个：
- 过于僵硬（Rigidity）：比如在系统中新增一个功能，会变得非常复杂，涉及到很多模块的调整，这就是系统僵硬的体现。
- 过于脆弱（Fragility）：比如对程序中某一个地方的修改，导致看上去没有什么关系的其他地方产生了影响，修改的同时，没有人能预测改动会给系统带来什么风险。
- 复用率低（Immobility）：比如想使用程序中已有的一段代码、函数、模块时，这些已有的代码总是依赖一大堆其它的东西，很难将它们独立出来使用。
- 黏度过高（Viscosity）：如果一个系统设计，不能简单的复用一个类或者通过接口来实现扩展，想扩展一个系统功能，必须破坏原始架构，就是黏度过高。
一个好的系统设计应该有如下的性质：
可扩展性（Extensibility）：可以很容易的在系统中加入一个新的功能。
灵活性（Flexibility）：可以很容易的实现对某个代码的修改，而不担心对其他模块产生影响。
可插入性（Pluggability）：可以很容易的将一个类抽出去复用，或者将另一个有同样功能的接口的类加入到系统里。 常用的面向对象设计原则有6个，这6大设计原则都是以可维护性和可复用性为基础的，这些原则并不是孤立存在的，它们相互依赖相互补充，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。
OCP（开闭原则，Open-Closed Principle）;
一个软件实体 如类,模块和函数应该对扩展开放，对修改关闭;
DIP（依赖倒置原则，Dependence Inversion Principle）;
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 即针对接口编程，不要针对实现编程.
LoD/LKP（迪米特法则，Law of Demeter / Least Knowledge Principle）;
又叫最少知识原则，一个软件实体应当尽可能少的与其他实体发生相互作用，通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少. 低耦合，高内聚
CARP (组合/聚合复用原则，Composition/Aggregation Reuse Principle);
尽量使用组合和聚合少使用继承的关系来达到复用的原则.
ISP (接口隔离原则，Interface Segregation Principle);
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少.
LSP (里氏替换原则，Liskov Substitution Principle);
子类可以扩展父类的功能，但不能改变父类原有的功能
SRP (单一职责原则，Single Responsibility Principle);
一个类负责一项职责.
