设计模式
2020-09-29 15:50:25 0 举报AI智能生成
设计模式脑图
作者其他创作
大纲/内容
行为型模式
访问者模式
在不改变数据结构的前提下，增加作用于一组对象元素的新功能。
模板模式
定义一个算法结构，而将一些步骤延迟到子类实现。
策略模式
定义一系列算法，把他们封装起来，并且使它们可以相互替换。
状态模式
允许一个对象在其对象内部状态改变时改变它的行为。
观察者模式
对象间的一对多的依赖关系。
备忘录模式
在不破坏封装的前提下，保持对象的内部状态。
中介者模式
用一个中介对象来封装一系列的对象交互。感觉微服务中的注册发现服务组件挺类似
迭代器模式
一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构。
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器。
命令模式
将命令请求封装为一个对象，使得可以用不同的请求来进行参数化。
主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
责任链模式
将请求的发送者和接收者解耦，使的多个对象都有处理这个请求的机会。
意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
感觉类似SpringMVC中前端控制器（dispacterServlet）,通过HandelerMaping控制器映射器获取的链（过滤链）
设计原则
单一职责原则
一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
开闭原则
一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
里氏替换原则
所有引用基类（父类）的地方必须能透明地使用其子类的对象。
依赖倒置原则
抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
接口隔离原则
使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
迪米特法则
一个软件实体应当尽可能少地与其他实体发生相互作用。
创建型模式
单例模式
某个类只能有一个实例，提供一个全局的访问点。
1、多模块访问同一个数据源连接对象
2、线程池
工厂方法模式
定义一个创建对象的接口，让子类决定实例化那个类。
抽象工厂模式
创建相关或依赖对象的家族，而无需明确指定具体类。
建造者模式
封装一个复杂对象的构建过程，并可以按步骤构造。
场景：比如创建一辆车的对象，一辆车由发动机、外骨骼等组成，而不同种的车其发动机、外骨骼也不同，那么在创建复杂对象（车）时，根据不同发动机、外骨骼的实现，组装成复杂对象
原型模式
通过复制现有的实例来创建新的实例。
场景：创建比较耗资源的对象时、一个对象供给多个修改者时
简单工厂模式
一个工厂类根据传入的参量决定创建出那一种产品类的实例。
场景：报表的生成
结构型模式
适配器模式
将一个类的方法接口转换成客户希望的另外一个接口。
通过继承或依赖实现
桥接模式
将抽象部分和它的实现部分分离，使它们都可以独立的变化。
继承关系转化成关联关系
组合模式
将对象组合成树形结构以表示“”部分-整体“”的层次结构。
装饰模式
动态的给对象添加新的功能。
外观模式
对外提供一个统一的方法，来访问子系统中的一群接口。
这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
享元模式
通过共享技术来有效的支持大量细粒度的对象。
代理模式
为其他对象提供一个代理以便控制这个对象的访问。
0 条评论
下一页
