android 策略模式和代理模式,秒懂设计模式之策略模式(Strategy Pattern)

前言

人在IT江湖飘,不懂设计模式咋装X?

我们这个社会上的事情大概率都符合八二法则,软件领域也一样。例如你学习一门编程语言,工作中常用的类来来回回也就那么几十个。那么多设计模式,最常被人使用的也就那么几种,所以我们在做事情的时候应该首先着眼于那20%。

策略模式算是设计模式中简单而又常用的了。

定义

策略模式定义了一系列的算法,并将每一个算法封装起来,使他们可以相互替换。

使用场景

当你写代码的时候发现一个操作有好多种实现方法,而你需要根据不同的情况使用if-else等分支结构来确定使用哪种实现方式的时候,想一想这个模式。

如何实现

业务场景

2017年的2月14号,王二狗和牛翠花约好在天津之眼约定终身,二狗打扮一番后准备出发,此时问题来了:是坐公交去呢,还是打滴滴快车呢?天气看起来也不错,要不骑共享单车吧,省钱还锻炼身体。

对应到编程领域就是:目前有三种策略可以实现一个特定的目的,使用何种策略取决于调用者(客户端)

普通实现

如果我们正常写代码,平时也应该这样,首先保证把功能正确的实现了,然后慢慢重构,设计模式都是在不断的重构当中应用的。 王二狗会调用会调用goToTianJinEye()方法,根据自己的实际情况,选择某一种出行方式。

public class TrafficFeeCalculator {

public int goToTianJinEye(String way, int distance) {

int trafficFee = 0;

switch (way) {

case "bus":

if (distance < 10)

trafficFee = 4;

else

trafficFee = 6;

break;

case "didi":

if(distance<3)

trafficFee = 8;

else

trafficFee=8+(distance-3)*3;

break;

case "sharedBicyle":

trafficFee = 2;

break;

default:

break;

}

return trafficFee;

}

}

那么这么写有什么弊端呢?

第一:每一种出行方式的交通花费的计算方式都写在了TrafficFeeCalculator类中,这个类承担的职责较多,违反了单一职责原则。

第二:假如王二狗突然想自己开车去,那就需要修改goToTianJinEye这个方法了。违反了开闭原则。

使用策略模式

以上的场景非常适合使用策略模式,将多种不同的实现算法封装,然后客户端根据不同策略分别调用相应的算法。

bde4f123b430fef551460c41f8d2d376.png

第一步:封装不同的实现算法

首先定义一个策略接口,规定算法的同一操作

public interface CalculateStrategy {

int calculateTrafficFee(int distance);

}

第二步:封装各个算法

//乘坐公交车算法

public class ByBus implements CalculateStrategy {

@Override

public int calculateTrafficFee(int distance) {

return distance<10?4:6;

}

}

//乘坐滴滴快车算法

public class ByDiDiExpress implements CalculateStrategy {

@Override

public int calculateTrafficFee(int distance) {

return distance<3?8:(8+(distance-3)*3);

}

}

//骑共享单车算法

public class BySharedBicycle implements CalculateStrategy {

@Override

public int calculateTrafficFee(int distance) {

return 2;

}

}

第三步:使用算法

public class TrafficFeeCalculator {

...

public int goToTianJinEye(CalculateStrategy strategy,int distance){

return strategy.calculateTrafficFee(distance);

}

}

第四步:客户端调用

根据情况,构建相应的算法类实例,传入计算器计算即可

public static void main(String[] args) {

TrafficFeeCalculator calculator=new TrafficFeeCalculator();

System.out.println(String.format("乘坐公交车到天津之眼的花费为:%d块人民币",

calculator.goToTianJinEye(new ByBus(),10)));

System.out.println(String.format("乘坐滴滴快车到天津之眼的花费为:%d块人民币",

calculator.goToTianJinEye(new ByDiDiExpress(),10)));

System.out.println(String.format("骑共享单车到天津之眼的花费为:%d块人民币",

calculator.goToTianJinEye(new BySharedBicycle(),10)));

}

输出为:

乘坐公交车到天津之眼的花费为:6块人民币

乘坐滴滴快车到天津之眼的花费为:29块人民币

骑共享单车到天津之眼的花费为:2块人民币

二狗为了早点见到自己心爱的牛翠花,最终选择了滴滴快车,贵是贵了点,但是快!

优缺点

优点:降低了算法类的职责,使各个算法可以独立变化并互相替换。而且使得增加新的算法变的很容易,降低了对原有系统的侵入,最终使得程序可扩展可维护性增强。

缺点:所有设计模式的通病,类增多了,程序从局部来看变的更复杂了。

总结

是不是感觉讲设计模式的文章都有一个特点,使用了设计模式反而比不使用设计模式使程序看起来更加复杂,而不是更加简单。那是因为每篇文章的示例都是无实际使用意义的示例代码,实际情况是程序非常复杂才需要使用到设计模式。一个大型程序是不断迭代出来的,一开始肯定不长那样,程序员日常接到一个开发任务也不要过多的想,这个我应该用个什么设计模式呀?先把功能实现了,然后回头看看有没有遵循面向对象编程6大原则,如果没有想想怎么改进,然后设计模式就登场了。。。

设计模式值得你刻意练习!

本文同步分享在 博客“ShuSheng007”(CSDN)。

如有侵权,请联系 support@oschina.cn 删除。

本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值