设计模式的概念

设计模式简介

设计模式是一种最佳实践长期以来总结出来的解决一系列问题的一种套路。

使用设计模式的目的：代码重用、工程化

设计模式一般有多少种：23种、不设上限

设计模式的类型

设计模式的类型一共有四种：

1.创建型设计模式：创建对象的同事隐藏创建的业务逻辑

　　★工厂模式、★单例模式、★建造者模式、☆原型模式

2.结构型设计模式：将现有的类和对象在一起形成更强大的功能结构

　　★适配器模式、桥接模式、过滤器模式、组合模式、★装饰器模式、外观模式、享元模式

　　★代理模式

3.行为型设计模式：特别关注对象之间的通信：

　　★观察者模式、责任链模式、命令模式、解释器模式、中介模式、备忘录模式、★状态模式、

　　空对象模式、策略模式、模板模式、访问者模式

4.J2EE模式、MVC模式、拦截过滤器模式、MVVM模式

设计模式的七大原则

1.里氏替换原则

任何基类出现的地方子类都一定可以出现，子类可以在父类的基础上派生出新的功能。

注意：

　　用父类接收子类对象，是没有办法使用子类中特有的方法或者成员的，子类自己的方法和对象是被隐藏了

　　如果子类拥有和父类一样的属性活方法抑或是其他非私有成员，此时都会默认子类的非私有成员会隐藏父类相同的非私有成员，但是具体使用的是父类的非私有成员还是子类的非私有成员，主要看声明的类型，如果声明的类型是父类，那么调用的就是父类的非私有成员，如果是子类调用的就是子类的非私有成员。注意，隐藏不是覆盖。

2.虚方法

虚方法需要用virtual关键字声明，子类可以用override关键字重写父类的虚方法。但是要记住！虚方法有他自己特定的使用场景。

场景一：如果只是单纯写完之后就不用管了，那倒不如使用抽象方法。

如果使用虚方法，一般情况下，子类重写的方法是作为父类虚方法的扩展，子类重写方法执行完之后，一般情况还是需要执行一下父类的虚方法的（比如DbContext）

场景二：可以在任何情况下再子类中调用父类的虚方法，不用有什么心理压力，因为子类重写则调用子类，子类没有重写就调用父类，保证不会出错。而抽象方法子类一定要重新写。

3.抽象方法

抽象方法一定要存在于抽象类中

抽象方法没有方法体

子类继承了父类，则必须要实现父类的抽象方法

4.依赖倒置

依赖倒置是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖具体

接口只能包含一些未实现的方法，所以我们可以进一步理解接口的抽象是相较于子类对方法的实现。

接口的意义：

1.接口可以规范和约束我们的类型，一旦在接口中定义了未实现的方法声明，其实现接口的子类就必须实现声明的未实现方法。

2.在.net6的接口中是可以写方法实现的，而且子类是要是于父类接口方法一样的方法，即认为对其实施了重写，而不需要定义虚方法以及override关键字

3.通过接口实现多继承，如果多个接口中有同样的方法，那么是哪个接口接收这个类的对象，就调用那个接口的方法。如果子类重写了方法，那么就调用子类重写的方法。

5.开闭原则

对扩展开放，对修改关闭

6.单一职责原则

该原则提出，对象不应该承担太多职责，如果一个对象承担太多职责，至少存在两个缺点

1.一个职责的变化可能会消弱或者抑制这个类实现其他职责的能力。换句话说，这个类中的一个方法的改变可能会影响到这个类中的其他方法，而导致这个类的不稳定。

2.当客户需要对象的某一个职责时，他不得不把对象的其他不需要的方法一并包含进来。

  重点：把一个大类，按照领域或者业务拆分成小类

7.接口隔离原则

接口最小化，类最大化

多个接口比单个接口好，系统为了追求稳定应该依赖于能满足其使用的最小接口，而不应该依赖于其不需要的接口

降低类之间的耦合度，由此可见设计模式就是从大型软件架构出发，便于升级和维护的软件设计思想，他强调，降低依赖、降低耦合。

8.迪米特法则

最小知道原则：一个实体应该尽少的与其他实体之间发生相互作用，使系统的模块能够相互独立。

9.合成复用原则

尽量使用合成和聚合，而不是使用继承

依赖、关联、

依赖：被依赖的类，一般会在依赖类中以返回值、形参、局部变量的形式出现

关联：关联按时依赖，但是耦合关系更强，被依赖的类成为依赖类的属性 （比如车的颜色）

  单向关联、双向关联、自生关联、多维关联

聚合：展示集体和个体之间的关系 （公司和员工）

组合：个体与组成部分之间的关系  （汽车和轮胎）

小结：

其中设计原则时在设计模式中必须尽量遵守的原则。