从我们经常写的项目里面用到的一些东西来看看都用了哪些设计模式:
从底层往上说,数据持久层的增删改查基本操作用写一个接口(IDataProvider),然后继承接口用ado.net来实现数据库访问，
ado具体类里面要做字段跟dataTable之间的映射,每个实体类都是不同的,在基类里面用一个IMapper Mpper{get;set;}抽象出来,
每个基类的再具体创建【工厂方法模式】, 对于有些操作你要特殊定制,要重写基类的virtual虚方法【模板方法模式】，
为了让系统试验多种数据库,你再用EF写了一个基于mssql的持久层,继承(IDataProvider),多种提供程序可以选择【抽象工厂模式】,
然后是业务层Service,操作方法传入接口变量是（IDataProvider provider）,而不是具体实现类的变量【桥接模式】,
所有Sercie都实现同一个接口IService,并且定义公共的方法【外观模式】，
在servcie的基类里面只有用ID删除数据的方法,你想实现一个直接用实体对象作为参数来删除数据的方法【适配器模式】，
用公用的缓存容器来存储数据【享元模式】, 如果将缓存的数据序列化后进行保存,然后反序列化提取【原型模式】
处理具体业务时候, 比如你想针对不同季节或节日对商品的价格设置不同方案,而这个方案经常变动或添加,
为了不经常改动购买流程的代码,将价格方案抽象处理,单独实现【策略模式】，后来公司为了精准销售, 对不同等级的
客户 不同类别的商品, 甚至根据商品的库存量, 做了不同的价格方案, 这个时候简单的策略模式已经无法满足业务需求,
不是因为用户等级会变,而是因为决定商品价格的因素是不定的, 如果用策略模式, 那调用策略的接口参数将会不停的改,
特别是针对已存在的策略是一件很危险的事情, 所以这边在调用的时候将整个对象数据传给策略的实现方【访问者模式】,
其他的设计模式的使用常态:
树形菜单: 组合模式
以接口作为参数: 桥接模式
HttpModel(.netcore中间件): 职责连模式
webSock广播: 观察者模式
CQRS: 命令模式
foreach指令： 迭代模式
内聚的设计模式: 状态模式, 外观模式, 迭代模式, 构建者模式
设计模式对比:
| 设计模式 | 相同点 | 不同点 |
| 命令模式 | 解耦 发送者跟接收者 | 通常只有一个特定接收者可以处理 |
| 职责链模式 | 每个接收者都可以处理,并且逐个尝试 |
| 设计模式 | 相同点 | 不同点 |
| 工厂方法 | 实现方式相似,都在子类实现，子类特殊化 | 创建对象 |
| 模板方法 | 重新方法 |
| 设计模式 | 相同点 | 不同点 |
| 策略模式 | 算法独立,解耦具体算法 | 对策略算法关闭,对调用者开发,先有策略，调用方不需要确定 |
| 访问者模式 | 对调用者关闭,对访问者开放,现在调用方埋回调方法,访问者后期可以添加新的 |
| 设计模式 | 相同点 | 不同点 |
| 访问者模式 | 实现方式都是在调用方,触发回调,埋入钩子 | 回调的参数通常是调用者对象callback(this), 钩子对象通常会访问多个多个地方。 |
| 中介模式 | 回调的参数通常是部分属性callback(this.prop)，钩子对象要指定中介的对象。 可以理解为特殊的访问者模式 |
| 设计模式 | 相同点 | 不同点 |
| 原型模式 | 备份数据 | 创建新对象,不用于还原 |
| 备忘录模式 |
备份状态参数，可以用于还原 |
| 设计模式 | 相同点 | 不同点 |
| 组合模式 | 实现方式都是继承共同的基类,并且包含该基类类型的成员 | 包含单个成员,线状 |
| 装饰模式 | 包含多个成员,树状 |
| 设计模式 | 相同点 | 不同点 |
| 适配器模式 | 借用第三方的类来实现功能,通常实现方法都是继承接口,然后包含第三方类来实现。 | 因为接口参数不匹配，需要调整参数 |
| 代理模式 | 因为安全/权限问题,接口参数不需要调整 |