策略模式在PHP业务代码的实践

【大话设计模式】-- 策略者模式(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到这种结构带来的好处。虽然在这个业务上，这种结构的优势并没有特别的明显，甚至可能有点增加代码量，但是我相信在后期扩展以及维护方便是有很大的好处的。记录这篇文章，主要是想要记录自己的思考方式以及学习体会，如果有一些不太对的地方欢迎大家指正，一起进步！！