敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能的简单、干净以及富有表达力
是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。
在进行一个改动时，可能会导致程序的说许多地方出现问题。
无法把该部分从系统中分离
软件粘滞性与环境粘滞性
ctrl+C ctrl+V
A 高层模块不应该依赖低层模块。两个都应该依赖抽象
B 抽象不依赖细节，细节应该依赖抽象
在软件里，把父类替换成子类，程序的行为没有变化。简单的说 ，子类型必须能够替换掉它们的父类型。
依赖倒转其实可以说是面向对象设计的标识，用哪种语言 来编写程序不重要，如果编写时考虑的都是如何针对细节编程，即程序中所有的依赖关系都是终止与抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了
子类型与父类之间的转换
1、子类可以隐士转换为父类（子类替换父类）
2、父类不能转换为子类，如果使用as关键字，子类为空。
是说软件实体（类、模块、函数等等）应该是可以扩展的，但是不可以修改。
1、对于扩展是开放的
2、对于更改是封闭的
怎样可能在不改动模块源代码的情况下去更改它的行为呢？如果不更改一个模块，又怎么能够去改变它的功能你？ 抽象
STRATEGY模式
TEMPLATEMETHOD模式
一个模型，如果孤立的看，并不具有真正意义上的有效性。模型的有效性之恩那个通过它的客户程序来表现。
一个类只有一个外部原因使他发生改变
之所以会出现单一职责原则就是因为在软件设计时会出现以下类似场景：
T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。
使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。