java设计模式

分类: Java

1 设计模式常用的七大原则有:

1.1 单一职责原则

简单说一个类只负责一项职责,只有逻辑足够简单,才可以在代码级别违反单一职责原则;只有类中方法足够少,可以在方法级别保持单一职责原则。

1.2 接口隔离原则

一个类对另一个类的依赖应该建立在最小的接口上。

1.3 依赖倒转原则

高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象;依赖倒转的中心思想是面向接口编程
依赖倒转的三种传递方式:
1.接口传递
2.构造方法传递
3.setter方式传递

1.4 里氏替换原则

在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法。在适当的情况下,可以通过聚合,组合,依赖来解决问题。

1.5 开闭原则

是编程中最基础最重要的设计原则,对扩展开放,对修改关闭;用抽象构建框架,用实现扩展细节。
尽量通过扩展实体的行为来shi实现变化,而不是通过修改已有的代码来实现变化。
编程中遵循其他原则,以及使用设计模式的目的就是遵循开闭原则。

1.6 迪米特法则

一个对象应该对其他对象保持最少的了解;
类与类关系越密切,耦合度越大;
迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。

1.7 合成复用原则

2 按模式分类

2.1 创建型模式

这类模式提供创建对象的机制, 能够提升已有代码的灵活性和可复⽤性。

2.1.1 工厂方法

业务场景:多种类型商品不同接⼝,统⼀发奖服务搭建场景。
实现要点:定义⼀个创建对象的接⼝,让其⼦类⾃⼰决定实例化哪⼀个⼯⼚类,⼯⼚模式使其创建过程延迟到⼦类进⾏。

2.1.2 抽象工厂

替换Redis双集群升级,代理类抽象场景。
实现要点:提供⼀个创建⼀系列相关或相互依赖对象的接⼝,⽽⽆需指定它们具体的类。

2.1.3 建造者

业务场景:各项装修物料组合套餐选配场景。
实现要点:将⼀个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。

2.1.4 原型

业务场景:上机考试多套试,每⼈题⽬和答案乱序排列场景。
实现要点:⽤原型实例指定创建对象的种类,并且通过拷⻉这些原型创建新的对象。

2.1.5 单例

业务场景:7种单例模式案例,Effective Java作者推荐枚举单例模式。
实现要点:保证⼀个类仅有⼀个实例,并提供⼀个访问它的全局访问点。

2.2 结构型模式

这类模式介绍如何将对象和类组装成较⼤的结构, 并同时保持结构的灵活和⾼效。

2.2.1 适配器

业务场景:从多个MQ消息体中,抽取指定字段值场景。
实现要点:将⼀个类的接⼝转换成客户希望的另外⼀个接⼝。适配器模式使得原本由于接⼝不兼容⽽不能⼀起⼯作的那些类可以⼀起⼯作。

2.2.2 桥接

业务场景:多⽀付渠道(微信、⽀付宝)与多⽀付模式(刷脸、指纹)场景。
实现要点:将抽象部分与实现部分分离,使它们都可以独⽴的变化。

2.2.3 组合

业务场景:营销差异化⼈群发券,决策树引擎搭建场景。
实现要点:将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得⽤户对单个对象和组合对象的使⽤具有⼀致性。

2.2.4 装饰

业务场景:SSO单点登录功能扩展,增加拦截⽤户访问⽅法范围场景。
实现要点:动态地给⼀个对象添加⼀些额外的职责。就增加功能来说,装饰器模式相⽐⽣成⼦类更为灵活。

2.2.5 外观

业务场景:基于SpringBoot开发⻔⾯模式中间件,统⼀控制接⼝⽩名单场景。
实现要点:为⼦系统中的⼀组接⼝提供⼀个⼀致的界⾯,外观模式定义了⼀个⾼层接⼝,这个接⼝使得这⼀⼦系统更加容易使⽤。

2.2.6 享元

业务场景:基于Redis秒杀,提供活动与库存信息查询场景。
实现要点:运⽤共享技术有效地⽀持⼤量细粒度的对象。

2.2.7 代理

业务场景:模拟mybatis-spring中定义DAO接⼝,使⽤代理类⽅式操作数据库原理实现场景。
实现要点:为其他对象提供⼀种代理以控制对这个对象的访问。

2.3 行为模式

这类模式负责对象间的⾼效沟通和职责委派。

2.3.1 责任链

业务场景:模拟618电商⼤促期间,项⽬上线流程多级负责⼈审批场景。
实现要点:避免请求发送者与接收者耦合在⼀起,让多个对象都有可能接收请求,将这些对象连接成⼀条链,并且沿着这条链传递请求,直到有对象处理它为⽌。

2.3.2 命令

业务场景:模拟⾼档餐厅⼋⼤菜系,⼩⼆点单厨师烹饪场景。
实现要点:将⼀个请求封装成⼀个对象,从⽽使您可以⽤不同的请求对客户进⾏参数化。

2.3.3 迭代器

业务场景:模拟公司组织架构树结构关系,深度迭代遍历⼈员信息输出场景。
实现要点:提供⼀种⽅法顺序访问⼀个聚合对象中各个元素, ⽽⼜⽆须暴露该对象的内部表示。

2.3.4 中介者

业务场景:按照Mybatis原理⼿写ORM框架,给JDBC⽅式操作数据库增加中介者场景。
实现要点:⽤⼀个中介对象来封装⼀系列的对象交互,中介者使各对象不需要显式地相互引⽤,从⽽使其耦合松散,⽽且可以独⽴地改变它们之间的交互。

2.3.5 备忘录

业务场景:模拟互联⽹系统上线过程中,配置⽂件回滚场景。
实现要点:在不破坏封装性的前提下,捕获⼀个对象的内部状态,并在该对象之外保存这个状态。

2.3.6 观察者

业务场景:模拟类似⼩客⻋指标摇号过程,监听消息通知⽤户中签场景。
实现要点:定义对象间的⼀种⼀对多的依赖关系,当⼀个对象的状态发⽣改变时,所有依赖于它的对象都得到通知并被⾃动更新。

2.3.7 状态

业务场景:模拟系统营销活动,状态流程审核发布上线场景。
实现要点:允许对象在内部状态发⽣改变时改变它的⾏为,对象看起来好像修改了它的类。

2.3.8 策略

业务场景:模拟多种营销类型优惠券,折扣⾦额计算策略场景。
实现要点:定义⼀系列的算法,把它们⼀个个封装起来,并且使它们可相互替换。

2.3.9 模板方法

业务场景:模拟爬⾍各类电商商品,⽣成营销推⼴海报场景。
实现要点:定义⼀个操作中的算法的⻣架,⽽将⼀些步骤延迟到⼦类中。模板⽅法使得⼦类可以不改变⼀个算法的结构即可重定义该算法的某些特定步骤。

2.3.10 访问者

业务场景:模拟家⻓与校⻓,对学⽣和⽼师的不同视⻆信息的访问场景。
实现要点:主要将数据结构与数据操作分离。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注


Warning: error_log(/www/wwwroot/codegulu.cn/wp-content/plugins/spider-analyser/#log/log-1809.txt): Failed to open stream: Permission denied in /www/wwwroot/codegulu.cn/wp-content/plugins/spider-analyser/spider.class.php on line 2969