设计模式--开篇

一，开篇

1，设计模式

设计模式： 对软件中普遍存在（反复存在）的各种问题，提出的规范性解决方案，以解决项目的耦合性、内聚性、可扩展性、可维护性、重用性、灵活性、可靠性等；

2，23种设计模式：

创建型模式：
单例模式、工厂模式、抽象工厂模式、原型模式、建造者模式；
结构型模式：
适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式；
行为型模式：
模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、责任链模式；

3，六大原则：

1. 单一职责原则（Single Responsibility Principle）：

介绍： 对于类来说，一个类应该只负责一项职责，如A类有两个不同职责：职责1，职责2；当职责1需要作出调整时，可能会造成职责2发生错误；所以要将A的细粒度分解为A1，A2（至少也要从方法层面分解为方法1、方法2）；
分析：
1，降低类的复杂性，一个类只负责一项职责；
2，提高类的可读性、可维护性；
3，降低变更引起的风险；

2. 接口隔离原则（Interface Segregation Principle）：

介绍： 对于接口来说，客户端不应该依赖他不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上；
分析： 接口interface具有实现A、B、C、D等实现，ABCD直接可以不必联系，这时候就应该将interface按照ABCD隔离出多个接口，而不应都试用这一个接口；
事例：

接口隔离：

3. 依赖倒转原则（Dependence Inversion Principle）：

介绍：
1，高层模块不应该依赖底层模块，二者都应该依赖其抽象（接口、抽象类）；
2，抽象不应该依赖具体实现，实现应该依赖抽象；
3，依赖倒转思想是面向接口编程；
4，依赖倒转理念：相对于实现多变性，抽象的东西要稳定的多。以抽象搭建架构要比实现搭建的稳定的多；
5，使用抽象是为了更好的制定规范，不涉及具体操作，细节下放到实现中去完成；
分析： 传参设计抽象优于实现

4. 里氏替换原则（Liskov Substitution Principle）：

介绍： 对每个类型为T1的对象O1，都有类型为T2的O2，使得T1定义的程序中O1替换为O2时，程序没有发生变化，则T2是T1的子类型，即所有使用基类的地方都透明的使用其子类对象；
分析：
1，在使用继承的时候尽量不要去重写父类方法；
2，继承实际上增加了程序的耦合性，在适当情况下可以使用聚合、组合、依赖等来解决；

5. 开闭原则（Open Closed Principle）：

介绍： 程序设计中最基础、最重要的原则；
分析：
1，一个类应该对扩展开放（对于提供方易于扩展），对修改关闭（对于使用方不能修改）。用抽象构建框架，有实现构建细节；
2，需求发生变化时，尽量使用扩展新的实现来完成，而不是修改已有的代码（防止对别人之前的调用造成影响）；

6. 迪米特原则（Demeter principle）：

介绍： 又叫最少知道原则 一个对象应该对其他对象保持最少了解，类与类关系越紧密，耦合越强。也就是说，对于被依赖的类不管多么复杂，都应该将逻辑封装在类的内部，对外除了提供的public方法外，不对外暴露任何信息；
分析： 核心是降低类之间的耦合，但是不是完全不依赖

4，类关系：

UML： 对于类关系的一种建模；
1，依赖关系：存在联系即为依赖；
2，泛华关系：继承,；
3，实现关系：实现；
4，关联关系：关联（如：对象以属性存在），具有导航性和多重性；
5，聚合关系：整体和局部的关系，整体和局部是可以分开的，属于关联关系，如set方式存在；
6，组合关系：整体和局部的关系，但是整体和局部不可分开，一般以属性方式存在，并且new的新式直接创建；

注： 文章内容来源于尚硅谷免费视屏教程