代理模式(委托模式)
- 定义:为其他对象提供一种代理以控制控制对这个对象的访问。
- 简而言之:我拿着你的实例,调用你的方法,替你操作或者管理。
优点
- 职责清晰
- 高扩展性:
因为代理类也实现了抽象主题接口,所以,真实主题需要调用的方法,代理类里面都能够去调用。 - 智能化:待补充。
扩展
普通代理
1、简单来讲就是客户端只能访问代理角色,而不能访问真实角色。
2、可以理解没代理类包裹真实类,并且真实类无法被单独调用。
3、真实主题类可以再代理类中实现。强制代理
通过真实的角色找到代理类。只有调用真实获得的代理类才能对象真实类进行操作。eg:你找一个老板做交易,老板要求你找他的秘书。他不管这类事情。动态代理
在实现阶段不用关心代理谁,而在运行阶段才指定代理哪个对象(自己写代理的方式都是静态代理)。
总结:利用java自带的接口,实现一个代理类,然后进行调用。可以根据场景,进行封装管理。
原型模式
- 定义:用原型来创建指定对象种类,通过拷贝该对象在内存中的数据创建新的对象。
-
自我理解:对象通过实现Cloneable接口,通过重写clone方法,让该对象能够通过调用clone方法实现内存拷贝,并且创建一个新的实例。(克隆的过程,即新对象产生的过程是从堆内存中以二进制流的方式进行拷贝原对象,重新分配一个内存块,因此构造方法不会被调用。)
浅拷贝
- 浅拷贝:实现中只进行对象克隆的时候,对于私有成员变量,新克隆出的对象的私有成员变量的引用是原型对象的成员变量地址。
- 注意:能够被拷贝的成员变量必须满足一下两点才能够被拷贝。
1、必须是成员变量,而不失方法内变量。
2、可变的。如果是原始数据类型,或者final对象的话也无法拷贝。
深拷贝
- 为了让原型对象和克隆对象的私有成员变量引用分开来,让他们拥有自己单独的成员变量对象。需要对成员变量进行clone赋值。克隆后,克隆对象的成员变量状态是克隆时刻原型对象的状态。
- 注意:克隆中,clone和final是不能同时引用的,当final修饰的时候,成员变量无法进行深度拷贝。
中介这模式(调停者模式)
- 官方定义:用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地互相作用,从而使其耦合松散,并且可以独立地改变他们之间的交互。
-
简单来说,a b c 两两相互依赖,对于这种情况,创建一个中间,用这个中间来跟a b c进行沟通调用。使其耦合松散。
- Mediator 抽象中介对象,定义统一接口,各同事角色之间通信。
- ConcreteMediator 具体中介角色,继承抽象中介对象。
- Colleague 同事角色,每一个Colleague必须在创建的时候加入中介依赖。
简单总结
- 优点:
松耦合 - 缺点:
单同事类数量比较多的时候,业务场景比较复杂时,这个中介会显得非常臃肿,逻辑关系也会变得非常复杂。 - 场景
android 中的Activity其实就是一个中介、mvc框架、媒体网关
命令模式
- 定义:
将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排排队或者记录请求日志,可以提供命令的撤销和恢复功能。 -
自我理解:
自然模式下,我叫a做第一件事情,叫b做第二件事情,叫c做第三件事情,相当于一个一个的对接做事。而命令模式下,我把要做的事情整理成一份命令清单,直接交给某个管理者(invoke),让他直接统筹命令清单。重点是把多个命令封装成一个任务集合,然后在某个场景下直接执行吧。
- Receiver接受者
跟工作任务相关需要干活的角色。一般情况下,会将receiver封装进command中,不在receiver在场景中出现。最终还是根据场景以及事务的关系情况看是否需要将receiver封装。 - Command命令
任务集合,以及所有角色好任务的详细的安排。 - Invoker调用者角色
接受命令,并且执行命令。可以理解成某个管理者,统筹的人。
其他
- 命令撤销
1、添加新命令执行撤销
2、结合备忘录模式还原最后的状态(后续实现) - 封装Receiver
1、该情况适场景而定。
责任链模式
- 定义:
使多个对象都有机会处理请求,从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连接成一条链,并源着这条链传递请求,知道有对象处理它或者整条链遍历结束。 - 理解:
责任链和核心个人认为就是讲匹配的条件由原来单个松散的个体,统一成一个链式结构,组成一条链,格局next来进行条件匹配。 -
责任链和if ...else if....和switch case
他们有相似之处,目的都是条件匹配。但是责任链跟注重链,即条件的先后顺序,一旦链中的一个条件不满足,后续就没有操作了。而else if 却会继续执行。
责任链的原理应该是和switch case是相同的。
- Handler
每一个条件就是一个handler,该类里面包括了逻辑处理,已经关系设置(nexthandler),还有一些公共条件的设置。
优缺点
- 优点:有点的话,隔离了请求和处理。
- 缺点:当handler构成的环数量太多时候,处理麻烦。第二个,该结构类似递归,调试不方便有的情况。
装饰模式
- 定义:动态地给一个对象添加而外的职责。比直接生成子类更加灵活??
-
自我理解:
先说说相似,装饰模式有点像多次继承(继承的替代方案)。 结构关系:定义一个抽象类component,继承该抽象类,得到一个被装饰者。定义一个基础装饰类,该基础装饰类有两个点:一个是要继承抽象component,二是需要持有被修饰的对象。通过增加修饰方法或者修改内容,实现修饰功能。
- Component
接口或者抽象类,定义最核心对象,基础原始数据。 - ConcreteComponent
具体构件,Component的实现类。需要装饰的就是它。 - Decorator
基础修饰类。该类继承了Component。 - ConcreteDecorator
具体的修饰类
summary
- 优点
解耦合呗
继承的一个替代方案
方便扩展 - 缺点
类似继承的问题,当层数比较多的时候不方便管理。 - 场景
需要扩展一个类的某个功能 - 动态改变功能,能增能减
- 比较多数量的类需要扩展功能的时候,选装饰者模式还是可以的。
策略模式(政策模式)
- 定义:定义一组算法,将每个算法都封装起来,并且使它们之间可以互换。
-
自我理解:android中使用到的context,我们通过context能够进行多种多样的操作,之所以能够执行这些操作是因为context里面封装了各种各样的方法供我们使用。所以类似这种就是策略模式。同时,他也是java 面向对象中 继承和多态的体现。
类图简单就不累赘了。创建策略,让context封装。场景中调用。
summary
- 优点
1、算法(策略)可以自由切换。用的是一个接口或者抽象类,传入的只要是其实例就ok了。
2、扩展性良好,想怎么玩就怎么玩。 - 缺点
1、策略类数量增多。
2、所有的策略类都需要对外暴露??
上层需要知道到底有哪些策略,这不是屁话么。留疑问??
扩展
有个好玩的东西叫枚举策略模式,没想到枚举还能这么玩。
直接上代码 ==》
https://github.com/cyp206/DesignModeLearning/blob/master/contentlib/src/main/java/com/mu/zi/contentlib/strategy_method_12/EnumStrategyScene.java
适配器模式
定义
将一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法再一起工作的两个类能够在一起工作。自我理解
两个实体类AB,分别继承了接口a b 。现在需要将B应用到A的应用场景之中(A、Bbean数据内容相同,但是结构不同)。这个时候,就采用到适配器模式。新建类C继承自B实现接口a,然后,C既可以调用B的数据,又能够适应于A的应用场景。
简单来说,就是类型转换并适应。-
类图
Target
期望接口Adaptee
源Adapter
转换角色
summary
- 优点
1、可以让两个没有关系的类运行在一起。
2、增加了类的透明性??
3、提高了类的复用度
4、灵活性非常好 - 场景
1、改模式使用于项目遵守里氏替换原则和依赖倒置原则(即面向接口编程)
2、这种模式一般是进行纠错处理,不是开发之初就想好了的。
迭代器模式——一个要快要被移出设计模式的设计模式
- 定义
它提供一种方法访问一个容器对象中各个元素,又不需要暴露对象的内部细节。 - 自我理解
为了遍历一个map,需要获得map的迭代器。所以,迭代器就是让你通过它来访问集合元素的一个管理工具。 -
类图
- Iterator
抽象迭代器定义访问和遍历元素的接口,first()、next()、isDone()(java叫hasNext()); - ConcreteIterator
Iterator具体实现类 - Aggregate
抽象容器 - ConcreteAggregate
具体容器
summary
- 迭代器现在应用得越来越广泛了,甚至已经成为一个最基础的工具。总的来说,可以了解这种思想,但是现在api都封装好了,自己实现还麻烦,蛋疼。