抽象工厂模式

开篇：

	前面讲了工厂模式在实际开发中的应用，我相信在电商业务中是完全可以用到的，但是用之前的模式的时候会需要修改“工厂类”的代码，会不方便，抽象工厂模
	式就是为了解决这个问题产生的。

抽象工厂：

	抽象工厂模式其实跟他的名字一样就是工厂模式，只不过多了“抽象”两个字，那这两个字的区别体现在哪里呢。“抽象”就是看不清楚的意思，是一系列的模糊描
	述。你让哪个工厂加工只有你知道，其他人不知道你让哪个工厂给你加工了。

业务说明：

	上次说订单支付模块，我已经把之前“丑陋”的代码进行了相应的优化之后，我的领导review我的代码之后，叫我过去谈话，问我这样写完之后，之后再加新的支
	付模式是不是得一直改工厂类代码进行判断，我心想我只是个CV(ctrl c v)高手你问我这么难的问题我怎么回答，但是我不能直接说出来，毕竟我得装作自己懂得
	样子，连忙回到好的好的马上回去改，一定下班前修改完。出了办公室回到工位上，马上使出了我的拿手好戏google搜索（为什么不是百度呢，因为B格），查
	了半天原来有个抽象工厂刚好符合leader的需求，嘴角微微扬起，果然没有什么问题可以难住我这个CV攻城狮。

原有工厂代码：

	    /**
	     * @param $payChannel
	     * @return WechatPay
	     * 获取服务
	     */
	    public function getService($payChannel)
	    {
	        if ($payChannel == 'wechat'){
	            return new WechatPay();
	        }
	        else if ($payChannel == 'ali'){
	            return new AliPay();
	        }
	    }

现在工厂代码：

	    /**
	     * @param $payClassName 支付类名
	     * @return object
	     * 获取服务
	     */
	    public function getService(payClass $payClassName)
	    {
	        return new $payClassName();
	    }

总结：

	这样就解决了每次都要去判断一下，抽象工厂其实很简单，和工厂模式其实差别在于“层次”，抽象更多的关注点在一系列工厂但是工厂更倾向于关注单个工厂。
	有关订单支付的服务中可以能每个支付类型的方法不同，可以增加适配类来解决适配的问题。（ps:抽象类工厂不是加了abstract关键字就不一样了）