新吴区住房和建设交通局网站中山币做网站公司
***************基础介绍***************
1、单一职责原则
2、里氏替换原则
3、依赖倒置原则
4、接口隔离原则
5、迪米特法原则
6、开闭原则
一、单一职责原则
举例：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
总结：一个类只负责一件事
1、情况
这里我们封装了一个动物类，写上两个方法，呼吸和行为。
运行方法
这里我们构造函数传入“鱼”的话，这样就不符合逻辑了
2、简单案例
我们把Animal类抽象为父类，然后把鸟、鱼等动物作为子类，去继承Animal。每个动物类内去重写各自的方法。互不影响。这就是单一职责原则
3、优点
一个类只负责一件事，拆分之后，职责变得单一。
阅读简单，易于维护。
扩展升级，减少修改，直接增加类。
方便代码重用。
4、缺点
类变多了，上端需要了解更多的类
5、使用时机
衡量着使用：如果类相对稳定，拓展变化少，而且逻辑简单，违背单一职责也没关系。 一个类不要让它太冗长
如果不同的职责，总是一起变化的，这种是一定要分开的。
6、举例
方法：方法多个分支，还可能拓展变化，最好分开多个方法
类：接收输入——数据验证——逻辑计算——数据库操作——日志，方便维护升级
接口：也会把不同的功能接口独立开来
类库：把项目拆分多个类库，重用——方便维护
项目：一个Web解决所有问题：客户端；管理后台；定时服务；远程接口；
二、里氏替换原则
基本：任何使用基类的地方，都可以透明的使用其子类
继承、多态
继承：通过继承，子类拥有父类的一切属性和行为，任何父类出现的地方，都可以用子类来代替
1、子类必须完全实现父类的方法，如果子类没有父类的某项东西，就断掉继承
2、子类可以有父类没有的东西，所以子类出现的地方，不一定能用父类来代替
3、透明（安全），父类的东西换成子类后不影响程序。
4、尽量不要new父类写完的方法，最好选择使用virtual和override的方式，避免埋雷
声明变量、参数、属性、字段最好都是基于基类的。
小题目：抽象类的父类有三个方法，Test01是普通方法，Test02是虚方法，Test03是抽象方法。子类继承了父类，重写了这3个方法。在实例化了子类后调用三个方法，调用的会是谁的方法？
答案是：父类、子类、子类
1、普通方法由左边决定，编译时决定
2、虚方法和抽象方法由右边决定，运行时决定
三、迪米特法则（最少知道原则）
基础：
1、一个对象应该对其他对象保持最少的了解。
2、面向对象——类——类与类之间会有交互——功能模块——系统
3、高内聚，低耦合。高度封装，类与类之间减少依赖
耦合关系：依赖、关联、组合、聚合 继承、实现接口。
4、只与直接的朋友通信
5、去掉内部依赖——降低访问修饰符
举例：我们有三个类，分别是学校类（School）、课室类（Class）和学生类（Student），课室中有学生，学生和学校没有直接联系，则学生是学校的依赖（间接关系）
学校的管理方式：
1、学校让班级自己去管理学生（符合迪米特法则）
2、学校直接管理所有学生（不符合迪米特法则）
参考示例：
四、依赖倒置原则
1、基础：上层模块应该依赖于底层模块，二者应该通过抽象依赖
依赖抽象，而不是依赖细节
小案例：我有一个手机基类，子类分别有IPhone类和HuaWei类，还有一个Student学生类，学生类可以玩IPhone和HuaWei手机，因此我们写了两个方法，可以传入两种手机的参数。但是如果我们希望后续给学生拓展更多的手机，那我们就要写更多的方法？
这种其实在方法里直接传入手机子类，其实算是依赖细节。
其实我们可以写一个方法，参数为手机基类（依赖抽象）：
1、依赖抽象更具有通用性，而且具备拓展性。
2、细节是多变的，抽象是稳定的；系统架构基于抽象来搭建，会更加具备拓展性
3、面向抽象编程，底层模块里面尽量都有抽象类/接口
4、在声明参数/变量/属性的时候，尽量都是 接口/抽象类
五、接口隔离原则
1、基础：客户端不应该依赖它不需要的接口；
一个类对另一个类的依赖应该建立在最小的接口上；
实现一个接口的时候，只需要自己必须的功能；
小案例：还是用上边手机的案例，我们刚刚通过抽象类来描述我们的手机，那对于我们手机的功能我们可以使用接口，抽象类主要用于是什么，接口主要用于干什么。
这里我写了一个接口，只需要继承这个接口，我们的手机就有打电话、上网、玩游戏等功能。但假如有一天我们需要假如一台老人机，而老人机并没有上网、玩游戏等功能，而我们这个接口就必须实现接口内的所有方法，这时候就不太合适了。最好的方法是把接口隔离开，比如所有手机都可以打电话，发短信，那么打电话和发短信就可以单独写一个接口，其他智能机才有的功能另外写一个接口。我们需要用什么接口就继承什么接口即可。
六、开闭原则
1、基础：1、对拓展开发，对修改关闭
2、如果有功能拓展变化的需求，希望是增加类而不是修改。
3、修改会影响原有功能，引入错误
4、增加类就不会影响原有的东西
5、原则的原则，五大原则是手段，开闭原则是目标