设计模式是什么鬼(策略)

简介: 设计模式是什么鬼(策略)

策略,Strategy,古时也称“计”,为了达成某个目标的方案,目标不同,方案也随之更改。例如特工执行任务时总要准备好几套方案以应对突如其来的变化,A计划实施过程中情况突变导致预案无法继续实施,则马上更换为B计划,正所谓计划不如变化快,提前策划固然非常重要,而随机应变更是不可或缺,只有保证这种可变的灵活性才能立于不败之地。世界永远都在变,唯一不变的就是变本身。


image.png


作为有思想的码农,我们当然也不能把程序写死了,一个设计优秀的系统,绝不是把现有类的代码改来改去,而一定是扩展类并接入系统,这样马上就能适应不同的用户需求。


就拿游戏机来举个例子,早期的俄罗斯方块风靡全球,后来国内流行一种掌机,只能玩俄罗斯方块这一个游戏,可过不了多久大家就玩腻了,于是热度降低这种游戏机很快就退出市场了,显然这是一种失败的设计模式。


image.png


后来任天堂出品的Game Boy以及Sony的PSP则完全带来了不同的用户体验,系统提供了统一的卡槽接口,玩家只要更换卡带或MD就可以达到更换游戏的目的,做到了一机多用。


image.png


各种游戏卡带,更换游戏方便多了。


image.png


好了,开始实战部分,为了说明问题,我们继续发扬极简主义的优良传统,我们就做一个最简单的计算器好了,假设我们的计算器只能进行加减法,代码如下。


1public class Calculator {//违反设计模式原则的做法
2    public int add(int a, int b){//加法
3        return a + b;
4    }
5
6    public int sub(int a, int b){//减法
7        return a - b;
8    }
9}


这样写ok吗?我们往后的扩展想想,如果随着我们的算法不断增加,如乘法、除法、次方、开方等等,那么这个计算器类就得不断的改啊改啊,每次升级算法我们都要把机器给拆开然后更改类代码,这岂不是作死?改到最后这个庞大的系统会不会变化这样?


image.png


或者是……如这般疯狂?


image.png


作死!的确是作死!我们来换个思路,先思考一下,既然不能把算法给写死在这里面,那一定要把这个算法给抽象一下,把实现细节从这个类里抽离出来,独立出来成为n个策略,就当下来讲我们一共有俩个策略,一个是加法策略,一个是减法策略,他们实现的都是同一个算法接口,接收参数为操作数a,以及被操作数b。


public interface Strategy {//算法标准
    public int calculate(int a, int b);//操作数,被操作数
}


下来实现加法策略、减法策略。


public class Addition implements Strategy{//实现算法接口
    @Override
    public int calculate(int a, int b) {//加数与被加数
        return a + b;//这里我们做加法运算
    }
}
public class Subtraction implements Strategy{//实现算法接口
    @Override
    public int calculate(int a, int b) {//减数与被减数
        return a - b;//这里我们做减法运算
    }
}


算法写好了,开始写计算器。


1public class Calculator {//计算器类
 2    private Strategy strategy;//拥有某种算法策略
 3
 4    public void setStrategy(Strategy strategy) {//接入算法策略
 5        this.strategy = strategy;
 6    }
 7
 8    public int getResult(int a, int b){
 9        return this.strategy.calculate(a, b);//返回具体策略的结果
10    }
11}


可以看到,计算器类里已经把之前的具体加减算法实现代码给剥离出去了,要用哪个算法,只需要注入进来,然后获得计算结果getResult实际上调用的是具体算法的calculate,我们来看怎样使用这个计算器。


1public class Client {
 2    public static void main(String[] args) {
 3        Calculator calculator = new Calculator();//实例化计算器
 4        calculator.setStrategy(new Addition());//接入加法实现
 5        int result = calculator.getResult(1, 1);//计算!
 6        System.out.println(result);//得到的是加法结果2
 7
 8        calculator.setStrategy(new Subtraction());//再次接入减法实现
 9        result = calculator.getResult(1, 1);//计算!
10        System.out.println(result);//得到的是减法结果0
11
12    }
13}


注释已经写得非常明白了,相信大家都看懂了吧。那么我们这个计算器可以说是具有算法策略扩展性的,以后要有新的算法是不需要再更改任何现有代码的,只需要新写一个算法比如乘法Multiplication,并实现calculate方法,接下来要做的只是组装上去便可以使用了。


计算器可以搞策略,那计算机呢?还记得我们在《设计模式是什么鬼(初探)》中举的计算机例子吧?很显然是同样是策略模式,大家可以自行写码试炼。


image.png


从以上的几个例子可以看出,我们的策略模式获得了极大的应用,策略实现类已经成为独立于宿主之外的模块,即插即用。可以组合成为一个整体,又可以分拆独立,可以发生关联,但绝不耦合,既对立又统一,这是唯物辩证法的绝佳体现。

相关文章
|
2月前
|
设计模式 安全 测试技术
【C/C++ 设计模式 单例】单例模式的选择策略:何时使用,何时避免
【C/C++ 设计模式 单例】单例模式的选择策略:何时使用,何时避免
64 0
|
2月前
|
设计模式 编解码 C++
【ffmpeg 视频播放】深入探索:ffmpeg视频播放优化策略与设计模式的实践应用(一)
【ffmpeg 视频播放】深入探索:ffmpeg视频播放优化策略与设计模式的实践应用
57 0
|
2月前
|
设计模式 存储 缓存
【ffmpeg 视频播放】深入探索:ffmpeg视频播放优化策略与设计模式的实践应用(二)
【ffmpeg 视频播放】深入探索:ffmpeg视频播放优化策略与设计模式的实践应用
30 0
|
1月前
|
设计模式 监控 Java
设计模式 - 观察者模式(Observer):Java中的战术与策略
【4月更文挑战第7天】观察者模式是构建可维护、可扩展系统的关键,它在Java中通过`Observable`和`Observer`实现对象间一对多的依赖关系,常用于事件处理、数据绑定和同步。该模式支持事件驱动架构、数据同步和实时系统,但需注意避免循环依赖、控制通知粒度,并关注性能和内存泄漏问题。通过明确角色、使用抽象和管理观察者注册,可最大化其效果。
|
1月前
|
设计模式 缓存 安全
分析设计模式对Java应用性能的影响,并提供优化策略
【4月更文挑战第7天】本文分析了7种常见设计模式对Java应用性能的影响及优化策略:单例模式可采用双重检查锁定、枚举实现或对象池优化;工厂方法和抽象工厂模式可通过对象池和缓存减少对象创建开销;建造者模式应减少构建步骤,简化复杂对象;原型模式优化克隆方法或使用序列化提高复制效率;适配器模式尽量减少使用,或合并多个适配器;观察者模式限制观察者数量并使用异步通知。设计模式需根据应用场景谨慎选用,兼顾代码质量和性能。
|
2月前
|
设计模式 编解码 算法
【ffmpeg 视频播放】深入探索:ffmpeg视频播放优化策略与设计模式的实践应用(三)
【ffmpeg 视频播放】深入探索:ffmpeg视频播放优化策略与设计模式的实践应用
33 0
|
4月前
|
设计模式 算法 调度
行为型设计模式:模板设计模式/观察者设计模式/策略设计模式/责任链设计模式
行为型设计模式:模板设计模式/观察者设计模式/策略设计模式/责任链设计模式
34 0
|
4月前
|
设计模式 算法 C++
【C++ 策略设计模式 】
【C++ 策略设计模式 】
|
9月前
|
设计模式 算法 搜索推荐
设计模式—策略(Strategy)模式
设计模式—策略(Strategy)模式
131 1
|
8月前
|
设计模式 算法
策略设计模式介绍与应用实战
策略设计模式介绍与应用实战
32 0