绪论：
-
设计模式是前辈们不断总结，不断打磨出的设计方法，不同设计模式适应于不同的场景
-
设计模式，公认的有23种设计模式，不同的设计模式适用于不同的场景
-
设计模式有优点，也有缺点不要为了使用设计模式而使用设计模式，切记防止“模式的滥用”
-
23种设计模式，其背后是7大设计原则。也就是说，每一个设计模式都归于一个或多个设计原则
-
7大设计原则的背后又是一个字，分。
-
7大设计原则，分别有：
a. 单一职责 b. 里氏替换原则 c.依赖倒置原则 d.开闭原则 e.迪米特法则
f.接口隔离原则 g. 组合优于继承原则 -
体会一下"分"字的威力：活字印刷术
-
学习设计模式，要始终绷紧2根线：a. 开发要分为两种角色(服务器端程序，客户端程序)
b. 我们手头并不会时时刻刻都拥有服务器端程序，即时有我们也不能修改
类和类之间的关系：
- 类和类之间的关系（UML类图）：依赖、继承、关联(组合和聚合)
- 继承：实线+三角箭头
- 关联：一个类的对象作为另一个类的字段或者属性 菱形+实线+箭头
组合（空心菱形）：关系弱
聚合（实心菱形）：关系强 - 依赖：一个类的对象作为另一个类的形参或者局部变量 虚线 +箭头
单一职责原则
- 每个类，每个方法，每个框架都只做一件事。 比如：Math.round()只负责完成四舍五入的功能，其他不管！Reader类，只负责读取文本文件（类） SpringMVC只负责简化
- 单一职责的缺点：代码的重用性不高，代码的可读性低
- 单一职责的优点：代码重用性提高，代码的可读性高(其实和封装的优点差不多)
开闭原则
- 开闭原则：对扩展新功能开发，对修改就功能关闭
- 例子：有一个刮胡刀，刮胡刀的作用就是刮胡子，现在想让刮胡刀具备吹风机的能力，违反开闭原则的原因就是把吹风功能加上，可能不能刮胡子，遵守开闭原则的原因就是把吹风功能加上，但是不能影响其刮胡子。
- 补充：一个类如果，从头到尾都是你自己写的，那么你可以修改源代码
一个类如果，从头不是自己写的，修改要符合开闭原则
接口隔离原则
- Animall类存在eat,swim,fly方法，但是不是所以动物都会游泳
- 可以将Animal分解为eat接口，swim接口，fly接口，避免接口之间的耦合，使用多个专门的接口比使用一个总接口要好
依赖倒置原则
- 依赖倒置：上层不能依赖于下层，它们都应该依赖于抽象（不应该依赖于具体，应该依赖于抽象）
- 什么是上层，什么是下层：调用别的方法就是上层，被调用的方法是下层
- 违反依赖倒置缺点：每当下层变动时，上层也要跟着变。我们希望当下层新增一个类时，上层应该“不知道”。
- 符合依赖倒置：所有下层应该都实现一个公共抽象类，上层和抽象类之间的关系是依赖关系
- 依赖倒置的优点：无论下层如何扩展，只要所有下层实现一个公共接口，上层代码不受影响
迪米特法则(最少知道原则)：
1.一个类对与一个类知道的越少越好，只和朋友通信
2. 什么是朋友? 类中的字段，方法的参数，方法的返回值，方法中的实例化对象
3. 迪米特法则的缺点：在系统中调用造出大量的小方法，这些小方法仅仅是传递间接的调用，与系统的业务逻辑无关。
里氏替换原则：
- 任何能使用父类对象的地方都应该能够透明的替换为子类对象。也就是说子类对象可以随时随地替换父类对象，且替换完不会报错，业务逻辑不会出现问题。
- 方法重写的两个限制：a.子类重写父类的方法时，子类方法的访问修饰符不能比父类的更严格 b.子类方法重写父类方法时，子类不能比抛出比父类更多的异常。
- 为什么要遵循这两个限制：这是为了保证子类对象替换父类对象时程序不需要改变和不会报错
- 继承的作用：提高代码重用性 多态的前提
- 两个类能不能发生继承关系的前提是什么？主要看有没有"is a"关系
- 两个类能不能发生继承关系的依据是什么？a.主要看有没有"is a"关系 b. 在有了"is a"关系后，还要考虑子类对象在替换父类对象之后业务逻辑是否发生变化！如果发生变化，则不能发生继承关系。
- 正方形和长方形有“is a"关系，但是我们不能让正方形直接去继承长方形。我们需要考虑业务场景，看看在特定的业务场景，正方形替换了长方形之后，业务逻辑是否变化？
组合优于继承：
- 继承是一个类继承另一个类。我们知道类和类之间的关系有3种：继承，依赖(一个类对象作为另一个类的局部变量)，关联(一个对象作为另一个对象的字段)。关联包括组合和聚合。组合关系强(大雁和翅膀)，聚合是关系弱(大雁和雁群)。
- 组合优于继承种的组合，其实指的是关联关系(也就是说关联优于继承)
- 如果父类作者和子类作者不是同一个人，就别继承；如何父类作者和子类作者是同一个人，就可以使用继承
