对设计模式的认识

1.设计模式分类

范围\目的创建型结构型行为型
类模式工厂方法模式(类)适配器模式解释器模式
模板方法模式
对象模式抽象工厂模式
建造者模式
原型模式
单例模式
(对象) 适配器模式
桥接模式
组合模式
装饰模式
外观模式
享元模式
代理模式
职责链模式
命令模式
迭代器模式
中介者模式
备忘录模式
观察者模式
状态模式
策略模式
访问者模式

2.各模式关键点

(1)创建型模式
简单工厂:一个工厂类根据传入的参量决定创建出那一种产品类的实例。
工厂方法:定义一个创建对象的接口,让子类决定实例化那个类。
抽象工厂:创建相关或依赖对象的家族,而无需明确指定具体类。
建造者模式:封装一个复杂对象的构建过程,并可以按步骤构造。
单例模式:某个类只能有一个实例,提供一个全局的访问点。
原型模式:通过复制现有的实例来创建新的实例。
(2)结构型模式
外观模式:对外提供一个统一的方法,来访问子系统中的一群接口。
桥接模式:将抽象部分和它的实现部分分离,使它们都可以独立的变化。
组合模式:将对象组合成树形结构以表示“”部分-整体“”的层次结构。
装饰模式:动态的给对象添加新的功能。
代理模式:为其他对象提供一个代理以便控制这个对象的访问。
适配器模式:将一个类的方法接口转换成客户希望的另外一个接口。
亨元(蝇量)模式:通过共享技术来有效的支持大量细粒度的对象。
(3)行为型模式
模板模式:定义一个算法结构,而将一些步骤延迟到子类实现。
解释器模式:给定一个语言,定义它的文法的一种表示,并定义一个解释器。
策略模式:定义一系列算法,把他们封装起来,并且使它们可以相互替换。
状态模式:允许一个对象在其对象内部状态改变时改变它的行为。
观察者模式:对象间的一对多的依赖关系。
备忘录模式:在不破坏封装的前提下,保持对象的内部状态。
中介者模式:用一个中介对象来封装一系列的对象交互。
命令模式:将命令请求封装为一个对象,使得可以用不同的请求来进行参数化。
访问者模式:在不改变数据结构的前提下,增加作用于一组对象元素的新功能。
责任链模式:将请求的发送者和接收者解耦,使的多个对象都有处理这个请求的机会。
迭代器模式:一种遍历访问聚合对象中各个元素的方法,不暴露该对象的内部结构。

先小学一下

3.策略VS模板模式

3.1实现姿势

3.1.1最low方式

假如现在有SEALOOK的三只海豹,都喜欢“吃饭,睡觉,打嗝”。

public class littleSeal {
    public void everyDay() {
        System.out.println("吃饭");
        System.out.println("睡觉");
        System.out.println("站着睡觉打嗝");
    }
}
public class middleSeal {
    public void everyDay() {
        System.out.println("吃饭");
        System.out.println("睡觉");
        System.out.println("水里打嗝");
    }
}
public class bigSeal {
    public void everyDay() {
        System.out.println("吃饭");
        System.out.println("睡觉");
        System.out.println("趴着打嗝");
    }
}
public class test {
    public static void main(String[] args) {
        System.out.println("littleSeal:");
        littleSeal Seal_01 = new littleSeal();
        Seal_01.everyDay();
        
        System.out.println("middleSeal:");
        middleSeal Seal_10 = new middleSeal();
        Seal_10.everyDay();
        
        System.out.println("bigSeal:");
        bigSeal Seal_04 = new bigSeal();
        Seal_04.everyDay();
    }
}

这种方式是我们写代码时,最容易使用的方式,上手简单,也容易理解,目前看项目中陈旧的代码,经常能找到它们的影子,下面我们看怎么一步步将其进行重构。

3.1.2常规方式

“吃饭,睡觉,打隔” 其实都是独立的行为,为了不相互影响,我们可以通过函数简单进行封装:

public class littleSeal {
    public void eating() {
        System.out.println("吃饭");
    }
    public void sleeping() {
        System.out.println("睡觉");
    }
    public void burping() {
        System.out.println("站着睡觉打嗝");
    }
}
public class middleSeal {
    public void eating() {
        System.out.println("吃饭");
    }
    public void sleeping() {
        System.out.println("睡觉");
    }
    public void burping() {
        System.out.println("水里打嗝");
    }
}
// bigSeal相同,省略...
public class test {
    public static void main(String[] args) {
        System.out.println("littleSeal:");
        littleSeal Seal_01 = new littleSeal();
        Seal_01.eating();
        Seal_01.sleeping();
        Seal_01.burping();
        // 下同,省略...
    }
}

工作过一段时间的同学,可能会采用这种实现方式,我们有没有更优雅的实现方式呢?

3.1.3 模板模式

定义:一个抽象类公开定义了执行它的方法的方式/模板,它的子类可以按需要重写方法实现,但调用将以抽象类中定义的方式进行,属于行为型模式。

这 3 只海豹,因为 “吃饭,睡觉” 都一样,所以我们可以直接实现出来,但是他们 “打嗝” 的方式不同,所以封装成抽象方法,需要每个海豹单独去实现 “打嗝” 的方式。

最后再新增一个方法 everyDay(),固定每天的执行流程:

public abstract class Seal{
    public void eating() {
        System.out.println("吃饭");
    }
    public void sleeping() {
        System.out.println("睡觉");
    }
    public abstract void burping();
    public void everyDay() {
        this.eating();
        this.sleeping();
        this.burping();
    }
}

每只海豹单独实现自己 “打嗝” 的方式:

public class littleSeal extends Seal{
    @Override
    public void burping() {
        System.out.println("站着睡觉打嗝");
    }
}
public class middleSeal extends Seal{
    @Override
    public void burping() {
        System.out.println("水里打嗝");
    }
}
public class bigSeal extends Seal{
    @Override
    public void burping() {
        System.out.println("趴着打嗝");
    }
}

最后看调用方式:

public class test {
    public static void main(String[] args) {
        System.out.println("littleSeal:");
        littleSeal Seal_01 = new littleSeal();
        Seal_01.everyDay();
        System.out.println("middleSeal:");
        middleSeal Seal_10 = new middleSeal();
        Seal_10.everyDay();
        System.out.println("bigSeal:");
        bigSeal Seal_04 = new bigSeal();
        Seal_04.everyDay();
    }
}
3.1.4 策略模式

定义:一个类的行为或其算法可以在运行时更改,即我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象,策略对象改变 context 对象的执行算法,属于行为型模式。

我们还是先抽象出 3 个海豹的行为:

public abstract class Seal {
    public void eating() {
        System.out.println("吃饭");
    }
    public void sleeping() {
        System.out.println("睡觉");
    }
    public abstract void burping();
}

每只海豹单独实现自己 “打嗝” 的方式:

public class littleSeal extends Seal {
    @Override
    public void burping() {
        System.out.println("站着睡觉打嗝");
    }
}
public class middleSeal extends Seal {
    @Override
    public void burping() {
        System.out.println("水里打嗝");
    }
}
public class bigSeal extends Seal {
    @Override
    public void burping() {
        System.out.println("趴着打嗝");
    }
}

这里就是策略模式的重点,我们再看一下策略模式的定义 “我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象”,那么该 contex 对象如下:

public class behaviorContext {
    private Seal _Seal;

    public behaviorContext(Seal newSeal) {
        _Seal = newSeal;
    }
    public void setSeal(Seal newSeal) {
        _Seal = newSeal;
    }
    public void everyDay() {
        _Seal.eating();
        _Seal.sleeping();
        _Seal.burping();
    }
}

最后看调用方式:

public class test {
    public static void main(String[] args) {
        behaviorContext behavior = new behaviorContext(new littleSeal());
        behavior.everyDay();

        behavior.setSeal(new middleSeal());
        behavior.everyDay();

        behavior.setSeal(new bigSeal());
        behavior.everyDay();
    }
}

我们可以通过给 behaviorContext 传递不同的对象,然后来约定 everyDay() 的调用方式。

其实我这个示例,有点把策略模式讲复杂了,因为纯粹的策略模式,3 个海豹只有 burping() 方法不同,所以可以把 burping() 理解为不同的算法即可。

之所以引入 everyDay(),是因为实际的项目场景中,会经常这么使用,也就是把这个变化的算法 burping(),包装到具体的执行流程里面,所以策略模式就看起来没有那么直观,但是核心思想是一样的。

3.2 模板 vs 策略

我在选择模板模式和策略模式时,发现两者都可以完全满足我的需求,然后我到网上查阅了很多资料,希望能找到两种模式在技术选择时,能确定告诉我哪些情况需要选择哪种模式。

说来惭愧,到现在我都没有找到,因为网上只告诉我两种实现姿势的区别,但是没有说明如何具体选型。

3.2.1 网上观点

据我可以告诉他们是 99% 相同,唯一的区别是模板方法模式具有抽象类作为基类,而战略类使用由每个具体战略类实现的接口,两者的主要区别在于具体 算法 的 select。

使用 Template 方法模式时,通过子类化模板在编译时发生,每个子类通过实现模板的抽象方法提供了一个不同的具体 算法。

当客户端调用模板的外部接口的方法时,模板根据需要调用其抽象方法(其内部接口)来调用 算法。

相比之下,策略模式允许在运行时通过遏制来 select 算法,具体 算法 是通过单独的类或函数实现的,这些类或函数作为 parameter passing 给构造函数或构造方法。

上面讲的有点抽象,下面直接看具体对比。

相似:

  • 策略和模板方法模式都可以用来满足开闭原则,使得软件模块在不改变代码的情况下易于扩展;
  • 两种模式都表示通用 function 与该 function 的详细实现的分离,不过它们所提供的粒度有一些差异。

差异:

策略模式:

  • 它基于接口;
  • 客户和策略之间的耦合更加松散;
  • 定义不能被子类改变的 算法 的骨架,只有某些操作可以在子类中重写;
  • 父类完全控制 算法 ,仅将具体的步骤与具体的类进行区分;
  • 绑定是在编译时完成的。

模板模式:

  • 它基于框架或抽象类,甚至可以有一个具有默认实现的具体类。
  • 模块耦合得更紧密;
  • 它通过修改方法的行为来改变对象的内容;
  • 它用于在 算法 族之间切换;
  • 它在运行时通过其他 算法 完全 replace 一个算法 来改变对象的行为;
  • 绑定在运行时完成。
3.2.2 个人理解

对于有强迫症的我,没有找到问题的根源,总感觉哪里不对劲,我就说一下我对于两者区别的理解吧。

说实话,两种设计模式,我也就看到在实现姿势上有所区别,至于说的策略模式要定义统一接口,模板模式不这样做等,我不太赞同,因为我有时也会给模板模式定义一个通用接口。

然后也有人说,策略模式需要定义一堆对象,模板模式就不需要,如果有 10 个不同的海豹,模板模式不也是需要定义 10 个不同的海豹类,然后再专门针对特定的方法去实现么?

这两种设计模式,我感觉还没有到非此即彼的划分。

如果我没有固定的执行流程,比如只去打嗝,只需要对一个方法做具体抽象,我愿意选择策略模式,因为这个我感觉会让我需要使用的对象,更清晰一些。

如果我有固定的执行流程,比如 “吃饭、睡觉、打嗝”,我更愿意使用模板方法,可能是代码看多了,也看习惯了,更愿意用模板方法去规范代码固定的执行流程。

当然,我也可以将两者结合起来使用,比如我们可以用模板方法,去实现这 3 只海豹,但是对于 middlePenguin,可能有分为海豹少年 A、海豹少年 B、海豹少年 C,他们都喜欢隔壁的海豹妹妹,但是喜欢的方式不同,有暗恋的,有直接表白的,还有霸道总裁的,我可以用策略模式,去指定他们对海豹妹妹的表达方式。

3.3 实际场景

任何模式,都需要结合实际的场景来讲,才能更清晰。

这两个模式,可以在你之前做过的项目中,只要稍微留意一下,应该会发现它们其实是大量存在的。

比如很多框架代码,里面有很多固定的执行流程,有些逻辑是可以采用默认处理的方式,有些逻辑需要下游自己去实现,然后有些逻辑还需要提前预留钩子

比如在执行 process() 流程时,可能需要进行 preProcess() 的操作,那么这个 preProcess() 就是你预留的钩子,下游可以实现,也可以不实现。

4. 工厂模式

后面会结合模板模式,来讲解工厂模式,实战场景非常强。

4.1 问题引入

对于工厂模式,大家可能觉得会很 Low,不就是搞个类,然后专门生成一个具体的对象嘛,这有什么难的?

是的,工厂模式确实不难,但是问你一下,如果你的代码中有很多 if…else,你知道怎么通过工厂模式,把这些 if…else 去掉么?

嗯,工厂模式我会,但是和去掉 if…else 好像没有关系吧?

我举个例子,假如你遇到如下代码:

switch($taskInfo['type_id']) {
    //批量冻结订单
    case 1:
        $result = self::batchFrozen($row_key,1);
        break;
    //批量解冻订单
    case 2:
        $result = self::batchFrozen($row_key,0);
        break;
    //批量允许发货
    case 3:
        $result =self::batchReshipment($row_key);
        break;
    //批量取消发货
    case 4:
        $result = self::batchCancel($row_key);
        break;
    // 后面还有几十个case,省略...

既然你懂工厂模式,可以把 if…else 简单重构一下,那就开始你的表演吧。

什么?不会?!你刚才还是自己是会工厂模式,怎么突然就怂了呢?

既然不会,那就静下心来,虚心学习一下。

4.2 工厂模式

定义:它提供了一种创建对象的最佳方式,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象,属于创建型模式。

其实设计模式一般不会单一使用,通常会和其它模式结合起来使用,这里我们就将上一篇文章讲到的模板模式和工厂模式结合起来。

因为工厂模式,通常会给这些新创建的对象制定一个公共的接口,我们可以通过抽象类定义:

public abstract class Seal {
    public void eating() {
        System.out.println("吃饭");
    }

    public void sleeping() {
        System.out.println("睡觉");
    }

    public abstract void burping();

    public void everyDay() {
        this.eating();
        this.sleeping();
        this.burping();
    }
}

因为我们是结合了模板模式,所以这个抽象类中,可以看到模板模式的影子。

如果你只关注抽象的接口,比如 burping,那么这个就是一个抽象方法,也可以理解为下游需要实现的方法,其它的接口其实可以忽略。

看看每个海豹具体的实现:

public class littleSeal extends Seal {
    @Override
    public void burping() {
        System.out.println("站着睡觉打嗝");
    }
}
public class middleSeal extends Seal {
    @Override
    public void burping() {
        System.out.println("水里打嗝");
    }
}
public class bigSeal extends Seal {
    @Override
    public void burping() {
        System.out.println("趴着打嗝");
    }
}

这里是工厂方法的重点,需要构建一个工厂,专门用来拿海豹:

public class SealFactory {
    private static final Map<String, Seal> map = new HashMap<>();
    static {
        map.put("littleSeal", new littleSeal());
        map.put("middleSeal", new middleSeal());
        map.put("bigSeal", new bigSeal());
    }
    // 获取海豹
    public static Seal getSeal(String name) {
        return map.get(name);
    }
}

上面的逻辑很简单,就是通过一个 map 对象,放入所有的海豹,这个工厂就可以通过海豹的名字,拿到对应的海豹对象,最后我们看使用方式:

public class test {
    public static void main(String[] args) {
        Seal Seal_1 = SealFactory.getSeal("littleSeal");
        Seal_1.everyDay();
        Seal Seal_2 = SealFactory.getSeal("middleSeal");
        Seal_2.everyDay();
        Seal Seal_3 = SealFactory.getSeal("bigSeal");
        Seal_3.everyDay();
    }
}

输出如下:

吃饭
睡觉
站着睡觉打嗝
吃饭
睡觉
水里打嗝
吃饭
睡觉
趴着打嗝

现在,最开始抛的那个问题,能给出答案么?

4.3 问题解答

文章开头的这个示例,其实也是我最近需要重构项目中的一段代码,我就是用 “工厂模式 + 模板模式” 来重构的。

我首先会对每个方法中的内容通过模板模式进行抽象(因为本章主要讲工厂模式,模板模式的代码,我就不贴了),然后通过工厂模式获取不同的对象,直接看重构后的代码:

public class TaskFactory {
    @Autowired
    public static List<AbstractTask> taskList;
    private static final Map<String, AbstractTask> map = new HashMap<>();
    static {
        // 存放任务映射关系
        map.put(AbstractTask.OPERATOR_TYPE_FROZEN, new BatchFrozenTask());
        map.put(AbstractTask.OPERATOR_TYPE_REJECT, new BatchRejectTask());
        map.put(AbstractTask.OPERATOR_TYPE_CANCEL, new BatchCancelTask());
    }

    public static void main(String[] args) {
        String operatorType = AbstractTask.OPERATOR_TYPE_REJECT;
        AbstractTask task = TaskFactory.map.get(operatorType);
        ParamWrapper<CancelParams> params = new ParamWrapper<CancelParams>();
        params.rowKey = 11111111;
        params.data = new CancelParams();
        OcApiServerResponse res =  task.execute(params);
        System.out.println(res.toString());
        return;
    }
}

4.4 实际场景

这个场景就太多了,刚才给大家讲解的是去掉 if…else 的场景,然后在小米商城的支付系统中,因为海外有几十种支付方式,也是通过这种方式去掉 if…else 的,不过支付类的封装不是用的模板方法,用的的策略模式,虽然感觉两者差不多。

如果你直接 new 一个对象就能解决的问题,就用不到工厂模式了。

5. 结语

看完这篇文章,相信这 3 种设计模式,已经深深刻在你骨子里面了。

大家可以静下心来想想,自己之前做过的项目中,有哪些用到上面这 3 种设计模式,然后自己再结合具体的场景总结一下,我想你应该会有更深入的理解。

To be continued。。。。

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一支一支杨桃枝

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值