前言:设计模式并不是什么很高深的东西,至少不是那么“神乎其神”。说到底,设计模式就是一些设计思想。下面我们就走进项目,看看这些项目中这些思想是如何体现的。本系列文章会在后续文章中陆陆续续的,在恰当的时候介绍一些相应的设计模式,而不是一股脑的一起上。
设计模式
本篇文章主要是讨论的在业务层可以采用的或者常用的一些设计模式:
Factory Method
Decorator
Template Method
State
Strategy
Factory Method
相信很多朋友对这个模式很熟悉了,平时在项目中或多或少总能看到Factory, Provider等。确实Factory
Method一种创建型的模式,它的主要目的就是隐藏对象创建的细节。也就是说,客户程序(或者成为调用者)不用特定来什么创建某一种具体的类,也不依赖于特定的类,而且依赖接口或者抽象类,这样就达到了解耦,专业点的说法就是“依赖倒置”,更加直白的说法就是:客户程序可以使用很多不同的实现类,而保持代码不变。因为在需要的时候,传入一些信息,Factory
Methods就返回接口或者抽象类的实现类。
很多情况下,我们一般是这样来使用Factory Method模式的:建立一个Factory类,这个类有一个静态的方法,这个方法返回一个抽象的类或者接口。然后,客户程序(或者调用程序)就传入一些信息给Factory类来,要求Factory来创建相对应,需要的具体的实现类。
下面我们就看看一个Factory Method的UML图:

在上面的图中:
1. Client类通过Factory类得到了一个IProduct接口的实现类。Client只是提供了一些信息,但是不知道具体的类是如何创建的。
2. Factory类常常基于Client类传入的信息来决定到底创建那个具体类。
3. IProduct有两个具体的实现者:ConcreteProductA, ConcreteProductB.
理论就介绍到这里了,下面我们就看看项目中如何使用的。
例子的主要基于电子商务中的送货的场景:当用户在电子商务网站上面订购了一个货物的时候,我们就要决定采用哪种方式把货物最终送到用户那里:是航空邮寄,还是轮船配送(轮船又分为很多不同的种类)等等。我们常常根据货物的价格和订购的地址来决定哪种配送方式和速递公司对我们更加的省钱。
在这个场景中,OrderService类有一个Dispatch方法,这个方法就来决定用哪种方式把货物送出。
请看下图:

在上面的图中:
1. Client类通过Factory类得到了一个IProduct接口的实现类。Client只是提供了一些信息,但是不知道具体的类是如何创建的。
2. Factory类常常基于Client类传入的信息来决定到底创建那个具体类。
3. IProduct有两个具体的实现者:ConcreteProductA, ConcreteProductB.
理论就介绍到这里了,下面我们就看看项目中如何使用的。
例子的主要基于电子商务中的送货的场景:当用户在电子商务网站上面订购了一个货物的时候,我们就要决定采用哪种方式把货物最终送到用户那里:是航空邮寄,还是轮船配送(轮船又分为很多不同的种类)等等。我们常常根据货物的价格和订购的地址来决定哪种配送方式和速递公司对我们更加的省钱。
在这个场景中,OrderService类有一个Dispatch方法,这个方法就来决定用哪种方式把货物送出。
请看下图:
在上面的图中:
1. 只要实现了IProduct接口的,就说明它是一个产品:DefaultProduct和ProductDecorator
2. DefaultProduct是一个产品的实现类,而ProductDecorator就是一个来装饰产品的类,或者说通过ProductDecorator,我们为产品引入更多的特性。至于ProductDecorator为产品引入什么特性(例如,使得产品更加的美观,好用,便宜),有不同的具体的ProductDecorator子类来实现。
下面我们还是来看一个电子商务中的例子:
场景:在电子购物网站中,我们商品平时是以原价来出售的,如果是节日,那么就会打折,如果商品快断货了,或者很抢手,可能会相应的提价。
首先我们分析,拿打折来说,可能今天是元旦,打个折;同时可能商家想吐货,也同时打个折,那么这个折扣就是两个打折方案后的累计效果。我们不能总是去改改原有的Product类的逻辑,所以就通过组合的方式,把不同的打折策略组合进去,最后组合成为一个“打折后的商品”来实现我们的变化和需求。
我们建立如下的解决方案:
|