【大话设计模式】– 策略者模式(Strategy):它定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变法,不会影响到使用算法的客户。
策略模式的核心就是屏蔽内部策略算法,内部的算法是可以随时替换,对外部是没有感知的。若新增或修改内部的算法,只需要修改或者扩展相应的策略类,客户端的代码无需改动,符合设计模式中一个重要的原则:开闭原则。
一. 业务需求背景
1.需求目的:
用户可以进行对某种配置进行预约,到达配置的预约时间点,根据Redis队列的预约号执行预约,不同类型的配置预约操作逻辑完全不同。
2.流程图:
二. 使用策略模式的缘由
此业务由于是要支持不同配置的预约,以及后期可能会有很多种类型的配置,而且不同类型的配置又完成不同,如果直接编码,后期的扩展性以及维护性会比较麻烦。
1.正常代码实现:
<?php
public function makeReservation($mainkey){
$type = getReservationTypeByMainkey($mainkey);
switch($type):{
case 'A':
$this->reservationAConfig($mainkey);
break;
case 'B':
$this->reservationBConfig($mainkey);
break;
.....
}
}
private function reservationAConfig($mainkey){
//这里进行A配置的预约逻辑操作
}
private function reservationBConfig($mainkey){
//这里进行B配置的预约逻辑操作
}
private function getReservationTypeByMainkey($mainkey){
//根据预约号获取预约配置的类型
}
这样子的实现也是可以满足业务需求,代码的可读性也还好。但是会有一个问题,这种预约的配置种类会很多,会导致switch的语句会越来越多,也可能会修改一些预约配置逻辑。这样子的话就需要修改原来的代码,对于代码质量来说,这并不是一种好的现象。
2.策略模式实现
<?php
interface ReservationStrategy
{
//执行预约配置逻辑操作
public function makeReservation();
}
//策略处理类
class ReservationHandler
{
private $strategy = null;
public function __construct(ReservationStrategy $strategy){
$this->$strategy = $strategy;
}
//封装了策略执行的逻辑,所有执行的预约配置统一调用这个方法
public function makeReservation(){
$this->$strategy->makeReservation();
}
}
//A配置的具体策略类
class AReservationStrategy implements ReservationStrategy
{
public function makeReservation(){
//这里执行A配置的逻辑操作
;
}
class ReservationFacaory
{
public static function getReservationInstance($mainkey){
//这里可以根据预约号做具体逻辑生成策略对象
}
}
//预约控制器代码
class ReservationController
{
public function makeReservation($mainkey){
//根据工厂对象创建预约策略实例
$reservation = ReservationFacaory::getReservationInstance($mainkey);
//传入实例给策略处理类
$handler = new ReservationHandler($reservation);
//执行预约策略
$handler->makeReservation();
}
}
以上代码使用了工厂模式以及策略模式的结合,其中ReservationHandler类作为处理上下文的类,通过依赖注入相应的策略类,直接调用makeReservation方法。在客户端代码只需要调用此方法即可,即使后期预约逻辑也无需改动客户端的代码。在此业务需求,因为需求并不是很大,所以工厂类只是简单实现。如果想要更完善,工厂类根据反射机制以及约定好的类名动态生成实例,这样后期如果扩展类型,只需要实现相应的接口即可,无需改动其他代码,很方便扩展。
总结
实践才能出真知。以前看大话设计模式这本书,总觉得自己看了好多遍但是还是云里雾里的,不知道为什么需要这种代码结构。但是通过一个小需求设计这么一个结构,我很快就能get到这种结构带来的好处。虽然在这个业务上,这种结构的优势并没有特别的明显,甚至可能有点增加代码量,但是我相信在后期扩展以及维护方便是有很大的好处的。记录这篇文章,主要是想要记录自己的思考方式以及学习体会,如果有一些不太对的地方欢迎大家指正,一起进步!!