设计模式学习总结

本文旨在让大家更好理解每个模式的精髓,相关类图及代码可以自行搜索。

模式的原则:开闭原则(对修改关闭、对扩展开放)、里氏代换原则、依赖倒转原则、接口隔离原则、成/聚合复用、最少知识原则 共6个。


1、代理模式Proxy:比如修改对象Obj,可以加一个ObjProxy,代理控制了这个对象的权限等;一些前置、后置的检查可以在这里做。

2、单例模式Singleton:比如我想控制一个类在一个JVM中只能创建一个实例,则使用单例模式;

3、工厂模式Factory:比如先定义一个接口IRobot{answer();},再定义工厂接口及类RobotFactory, DbRobotFactory, RedisRobotFactory, 实现类 RobotDbImpl, RobotRedisImpl,这样可以根据情况创建不同的实现类。
4、生成器模式Builder:构造复杂对象;
5、原型模式Prototype:对象的复制(浅复制,深复制)

6、外观模式Facade::为一个复杂子系统提供一个简单接口,依赖解耦。方便调用者,将我内部的细节进行封装,并解耦。如系统做的下单接口,如商品同步商品中心、价格中心,就是外观模式的应用。

7、适配器模式Adaptor:在OO的过程中,有一些操作对象,不满足现有的接口定义,我们就建立一个Adaptor来将其适配进来。

8、观察者模式Observer:对一个主题,让多个观察者同时监听主题对象,这个主题对象在状态发生变化时,会通知所有观察者对象。用过MQ的应该容易理解。观察者模式定义了一种一对多的依赖关系。

9、策略模式Strategy:定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。(体现了OO基本的多态性)

10、装饰模式Decorator:装饰对象包含一个真实对象的引用(reference).装饰对象把客户请求转发给真实的对象,并在转发这些请求以前或者以后增加一些附加的功能。这样就能确保在运行时,不用修改给定对象结构就可以在外部增加附加的功能。与Proxy的区别,Decorator是在运行时动态确定真实对象的,并且客户是知道具体的真实对象的;而Proxy是对客户是透明的。

11、迭代器模式Iterator:提供遍历集合的简单、统一的方式。java中的Collection,List、Set、Map等,这些集合都有自己的迭代器。

12、责任链模式Chain Of Responsibility:首先交给第一个handler处理,它处理不了则交给nextHandler,如此反复,直到有能处理的handler处理为止,或不能处理为止。适合重构if..elseif..elseif..else的情况。缺点:当责任链比较长时,性能问题比较严重。

13、模板方法模式:先设计好完整的处理问题的框架(类、接口),而具体的算法、业务逻辑实现定义为抽象的、可覆盖的方法,由具体的业务实现者完成。目的是先将完整的流程串起来,之后再逐步具体实现。记得在线客服项目,阿超就是写好了聊天参与者的接口,我具体负责机器人应答实现的。

14、备忘录模式:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。以后随时可以恢复该对象的状态。

15、解释器模式Interpreter:解析文法用,用的比较少。

16、命令模式Command:Command是遥控器按钮,Receiver是电视机,Invoker是遥控器。

17、访问者模式:修改、扩展一个类不是直接修改它的方法,而是修改它的访问者的方法(关系不大且易变),保证该对象的稳定,并符合单一职责原则。元素类可以通过接受不同的访问者实现扩展。

18、桥接Bridge模式:一个业务对象,具有两个或两个以上的维度变化。通过对象组合的方式,Bridge 模式把两个角色之间的继承关系改为了耦合的关系,从而使这两者可以从容自若的各自独立的变化,这也是Bridge模式的本意。

19、组合模式:将组合为树形结构的对象,按照统一的方式进行操作(递归遍历),包括叶子节点和复合节点(非叶子节点)。

20、享元模式:享元模式采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。

21、中介模式:把大量对象间的错综复杂的联系(耦合),变成“星形结构”。由原来的网状结构到星形结构的转变,可以理解为就是中介者模式的作用。

22、状态模式:将对象的状态改变,实现为该对象的实现类的改变。从而使相关依赖于状态的操作简单化,OO化。



引用下别人说的:

对于一个场合到底用不用模式,这对所有的开发人员来说都是一个很纠结的问题。有时候,因为预见到需求上会发生的某些变化,为了系统的灵活性和可扩展性而使用了某种设计模式,但这个预见的需求偏偏没有,相反,没预见到的需求倒是来了不少,导致在修改代码的时候,使用的设计模式反而起了相反的作用,以至于整个项目组怨声载道。这样的例子,我相信每个程序设计者都遇到过。所以,基于敏捷开发的原则,我们在设计程序的时候,如果按照目前的需求,不使用某种模式也能很好地解决,那么我们就不要引入它,因为要引入一种设计模式并不困难,我们大可以在真正需要用到的时候再对系统进行一下,引入这个设计模式。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值