目录
- 前言
- oop思想
- 面向过程
- 面向对象
- 面向对象特点：
- 设计模式/原则
- 设计模式六大原则：
- 单一职责原则（Single Responsibility Principle）
- 里氏替换原则（Liskov Substitution Principle）
- 依赖倒置原则（Dependence Inversion Principle）
- 接口隔离原则（Interface Segregation Principle）
- 迪米特法则 （Law Of Demeter）
- 开闭原则 （Open Closed Principle)
前言
类与接口的区别；
类是为了说明是什么。
接口是为了限定做什么。
pop：procedure oriented programming 面向过程编程
oop：object oriented programming 面向对象编程
oop思想
面向过程
面向对象
面向对象特点：
继承、封装，多态；
-
封装：
就是对象的确定，隔离了内部的业务逻辑，外面根本不用去操心怎么实现，只要是让外部调用的方法名称不变，外面就不受影响；那么内部就可以自由扩展，修改；
数据安全，可以通过不同的访问修饰符，来限定外部是否可以调用；外面只能通过我定义的对完公开接口进行访问（不能随便修改）
降低耦合： 提高重用性；隐藏不想让别人看到的东西； -
继承：子类可以拥有父类的一切行为和属性，继承以后代码也可以重用；
单基类继承；就是是只能有一个父类；
重写，覆写，重载
重载：方法签名一样，但是参数列表不同；跟返回值没关系； -
多态：可以有不同的状态；一个类可以有多个类型来表示，当然还有方法； 运行时多态：虚方法 能不能类不让其他类来继承；
继承后多态；通过一个声明，来调用行为，执行的真正动作其实不一样； 接口多态：同一个接口声明，调用同一个方法，执行的却是不同的和业务逻辑Tips: 抽象类不可被实例；接口可以继承接口；
设计模式/原则
- 设计模式：面向对象语言开发过程中，遇到种种的场景和问题，提出的解决方案和思路，沉淀下来
- 设计模式六大原则：面向对象语言开发过程中，推荐的一些指导性原则
没有明确的招数，而且也经常会被忽视/违背
也是前辈总结，也是为了站在前辈的肩膀上 - 原则：建议，不是一定要使用；
设计模式六大原则：
单一职责原则（Single Responsibility Principle）
-
类单一职责：一个类只负责一件事儿；
-
类层面的单一职责：父类+子类；每个类只负责自己的事儿—增加扩展性；
-
方法层面的单一职责：每个方法只负责自己的事儿；把个件事儿拆分成不同的小方法来各自实现；每个方法就可以独立演变，增加了程序的稳定性；
-
类库层面的单一职责：每个类库要求职责清晰；三层架构 UI+BLL+DAL+Common
-
项目层面的单一职责：要求每个项目职责清晰：单体架构 MVC,所有的业务逻辑都写在一起；
-
原始版电商平台：会员的系统+商品系统+订单系统 如果是全部放在一起，代码耦合很高；修改一处，其他的都受到影响；
-
升级版电商平台：会员系统独立出来。。。。订单系统独立。。。。商品。。。。
-
可以让每个子系统可以独立演化；增强了程序的稳定性。。。
-
单一职责：大家视情况而定；并不是一定要遵循—我建议大家遵循；
-
拆分：父类+子类一个类只负责了一件事儿；每个类更加简单了；简单预示着强大；
-
代码量增加了；代码的可读性降低了；
-
为什么要遵循单一职责呢？增加扩展性
-
建议：如果代码很简单，没有必要去遵循单一职责
如果代码比较复杂，建议大家还是可以去遵循单一职责；
里氏替换原则（Liskov Substitution Principle）
-
里氏替换原则：任何使用基类的地方，都可以透明的使用其子类
-
继承+透明==正确的是使用继承；
1.任何父类出现的地方都可以用子类代替；
2.子类继承父类，必须拥有父类的一切行为和属性；如果子类出现不应该有的方法；
3.子类可以有自己的独立行为和属性，子类出现的地方，不一定可以让父类代替
4.父类出现的动作，子类就不要再写（不要使用new隐藏）—老师也强烈建议大家不要使用这个new
5.要求尽量使用父类类声明实例对象； -
说白了：老师觉得就是叫我们如何去正确的使用继承；为了解决之前的技术债
-
如果子类出现不应该有的方法，就应该断开继承,再来一个父类；
透明：
继承、多态
依赖倒置原则（Dependence Inversion Principle）
- 依赖倒置原则:上层模块不应该依赖于低层模块，二者应该通过抽象依赖
- 项目是分层架构的：A->B->C->D->E->F
- 如果是依赖于细节，那么如果F层发生需求编程，代码调整了，会导致E层也会不稳定，E层也要----。。。。。上层会成冒泡式修改。。。
- 如果依赖倒置以后：不再依赖于细节，而是依赖于抽象，抽象相对稳定，只要抽象不修改，高层就不受影响；如果F代码修改了，E依赖的是F的抽象，E不受影响，上层都不受影响；整个系统架构才是稳定的；
接口隔离原则（Interface Segregation Principle）
- 接口隔离原则:客户端不应该依赖它不需要的接口；
一个类对另一个类的依赖应该建立在最小的接口上； - 正确的使用接口
迪米特法则 （Law Of Demeter）
-
迪米特法则(最少知道原则):一个对象应该对其他对象保持最少的了解。
只与直接的朋友通信。 —最少知道别人的事儿，也尽量让别人最少知道自己的事儿；不好好奇心太重； -
面向对象开发：万物皆对象；一个功能的实现===多个对象交互产生；
类和类之间的关系：
纵向：继承、实现
横向：聚合>组合>关联>依赖(体现在方法内部) -
高内聚—低耦合；
为什么要遵循迪米特法则：就是为了能减低耦合；让代码更加稳定； 代码稳定，代码的健壮性，代码的安全—你们做了大型项目后悔有明显的感觉； -
成本：增加了复杂性，可读性也降低了；
-
迪米特法则的应用：三层架构—UI+BLL+DAL
门面模式：转移依赖耦合 -
要求私密性：正确的使用访问修饰；
public private protected interal
开闭原则 （Open Closed Principle)
-
开闭原则:对扩展开发，对修改关闭。
-
修改：修改现有代码(类)
扩展：增加代码(类) -
开闭原则建议：无论是功能的增加还是功能的修改，都通过增加代码（类）；
建议大家代码只增不改；—原有代码不修改，系统必然稳定； -
开闭原则其实是前面五大原则的总则；
-
增加方法—增加类—增加类库（可以生成dll文件 + 抽象约束+配置文件）
