设计模式，不是一种新的语言，也不是什么新的api更不是什么新的语法
设计模式是前辈们不断总结，不断打磨出的设计方法，不同设计模式适用于不同的场景
设计模式公认的有23种，分别对应23种设计场景，这些设计模式我们不用怀疑它的功能，因为这些设计模式是经过长期的实践考验，而留存下来的
千万不要以为有任何一种设计模式能解决任何问题，每一种设计模式是只能用于适用的场景而不是万能的
设计模式又有点也有缺点，我们不要为了使用设计模式而使用设计模式，切记防止模式的滥用
23种设计模式，背后其实是七大设计原则，也就是说，每个设计模式都归属于一个或多个设计原则
七大设计原则的背后又是：一个字，分
7大设计原则：a单一职责原则
b里氏替换
c依赖倒置原则
d开闭原则
e迪米特法则（最少知道原则）
f接口隔离原则
g组合优于继承原则
单一职责: 每个方法、每个类、每个框架都只负责一件事情。
比如：
Math. round(),只负责完成四舍五入的功能，其他它不管! (方法)
Reader类，只负责读取文本文件(类)
SpringMVC,只负责简化MVC的开发(框架)
开闭原则:
a.对扩展新功能是开放的
b.对修改原有功能是关闭的
比如：
有一个刮胡刀，刮胡刀的作用就是刮胡子，现在想让刮胡刀具备吹风机能力。
违反开闭原则的做法就是:把吹风功能加上了，可能不能刮胡子了。
符合开闭原则的做法就是:把吹风功能加上了，且没有影响以前的刮胡子功能。
接口隔离原则： 客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在 最小的接口上。
实现：把接口interface分开写，分别implement
UML图——类和类之间的关系：
继承：实线+空心三角形一
依赖： 作为形参，或局部变量
虚线+箭头
关联：没有继承，在另一个类里实例化
组合：关系强一些，无法分离，用实心菱形
聚合：关系弱一些，用空心菱形
依赖倒置原则：下层变动，上层不需要改动。。上层不依赖于下层，只依赖于抽象，下层只依赖于抽象，还是一个“分“字
迪米特法则（最少知道原则）：一个对象应当对其他对象有尽可能少的了解,不和陌生人说 话。
一个类，对于其他类，要知道的越少越好。
只和朋友通信：a.类中的字段
b.方法的参数
c.方法的返回值
d.方法中实例出来的对象
缺点：多出很多小方法，变为朋友，降低了通信效率。
里氏替换原则：任何能使用父类对象的地方，都应该能透明地替换为子类对象。
也就是说，子类对象可以随时随地替换父类对象，且替换完以后，语法不会 报错，业务逻辑也不会出现问题!
方法重写:
在子类和父类中，出现了返回类型相同、方法名相同、方法参数相同的方法时， 构成方法重写
方法重写的两个限制:
1.子类重写父类的方法时，子类方法的访问修饰符不能比父类的更严格
2.子类重写父类的方法时，子类方法不能抛出比父类更多的异常
为什么要有以上这2个限制。就是为了保证，代码符合里氏替换原则
由于比较懒，具体笔记放在了文档里，需要的下载吧
