通過面向?qū)ο蟮姆庋b蔑匣，繼承和多態(tài)來降低程序的耦合度劣欢。下面就讓我們來深入學(xué)習(xí)這個(gè)模式。
工廠模式：客戶類和工廠類分開裁良。消費(fèi)者任何時(shí)候需要某種產(chǎn)品凿将，只需向工廠請求即可。消費(fèi)者無須修改就可以接納新產(chǎn)品价脾。缺點(diǎn)是當(dāng)產(chǎn)品修改時(shí)牧抵，工廠類也要做相應(yīng)的修改。
一侨把、引子
話說十年前犀变，有一個(gè)爆發(fā)戶，他家有三輛汽車（Benz（奔馳）秋柄、Bmw（寶馬）获枝、Audi（奧迪）），還雇了司機(jī)為他開車骇笔。不過省店，爆發(fā)戶坐車時(shí)總是這樣：上Benz車后跟司機(jī)說“開奔馳車！”笨触，坐上Bmw后他說“開寶馬車懦傍！”，坐上 Audi后他說“開奧迪車芦劣！”粗俱。
你一定說：這人有病虚吟！直接說開車不就行了源梭？娱俺！而當(dāng)把這個(gè)爆發(fā)戶的行為放到我們程序語言中來，我們發(fā)現(xiàn)C語言一直是通過這種方式來坐車的废麻！
幸運(yùn)的是這種有病的現(xiàn)象在OO語言中可以避免了。下面以O(shè)C語言為基礎(chǔ)來引入我們本文的主題：工廠模式模庐！
二烛愧、簡介
工廠模式主要是為創(chuàng)建對象提供了接口。工廠模式按照《Java與模式》中的提法分為三類：
簡單工廠模式(Simple Factory)
工廠方法模式(Factory Method)
抽象工廠模式(Abstract Factory)
這三種模式從上到下逐步抽象掂碱，并且更具一般性怜姿。還有一種分類法，就是將簡單工廠模式看為工廠方法模式的一種特例疼燥，兩個(gè)歸為一類沧卢。兩者皆可，這本為使用《Java與模式》的分類方法改編之后的醉者。
在什么樣的情況下我們應(yīng)該記得使用工廠模式呢但狭？大體有兩點(diǎn)：
1.在編碼時(shí)不能預(yù)見需要創(chuàng)建哪種類的實(shí)例。
2.系統(tǒng)不應(yīng)依賴于產(chǎn)品類實(shí)例如何被創(chuàng)建撬即、組合和表達(dá)的細(xì)節(jié)
工廠模式能給我們的OOD立磁、OOP帶來哪些好處呢？剥槐？
三唱歧、簡單工廠模式
這個(gè)模式本身很簡單而且使用在業(yè)務(wù)較簡單的情況下。一般用于小項(xiàng)目或者具體產(chǎn)品很少擴(kuò)展的情況（這樣工廠類才不用經(jīng)常更改）粒竖。
它由三種角色組成：
工廠類角色：這是本模式的核心颅崩，含有一定的商業(yè)邏輯和判斷邏輯，根據(jù)邏輯不同蕊苗，產(chǎn)生具體的工廠產(chǎn)品沿后。如例子中的Driver類。
抽象產(chǎn)品角色：它一般是具體產(chǎn)品繼承的父類或者實(shí)現(xiàn)的接口岁歉。由接口或者抽象類來實(shí)現(xiàn)得运。如例中的Car接口。
具體產(chǎn)品角色：工廠類所創(chuàng)建的對象就是此角色的實(shí)例锅移。在java中由一個(gè)具體類實(shí)現(xiàn)熔掺，如例子中的Benz、Bmw類非剃。
來用類圖來清晰的表示下的它們之間的關(guān)系：
下面就來給那個(gè)暴發(fā)戶治仓寐摺：在使用了簡單工廠模式后，現(xiàn)在暴發(fā)戶只需要坐在車?yán)飳λ緳C(jī)說句：“開車”就可以了备绽。來看看怎么用代碼實(shí)現(xiàn)的：
//抽象產(chǎn)品
@interface Car : NSObject
@property (nonatomic, copy) NSString *strName;
- (void)drive;
@end
#import "Car.h"
@implementation Car
- (void)drive {
}
@end
//具體產(chǎn)品
//奔馳
@interface Benz : Car
@end
@implementation Benz
- (void)drive {
NSLog(@"Benz Car:%@", self.strName);
}
@end
// 寶馬車
@interface Bmw : Car
@end
- (void)drive {
NSLog(@"BMW Car:%@",self.strName);
}
@end
//簡單工廠
@interface Driver : NSObject
+ (Car *)createCar:(NSString *)strCar;
@end
@implementation Driver
+ (Car *)createCar:(NSString *)strCar {
Car *c = nil;
if ([strCar isEqualToString:@"Bmw"]) {
c = [[Bmw alloc]init];
}
else {
c = [[Benz alloc]init];
}
return c;
}
@end
//老板告訴司機(jī)我今天坐奔馳
Car *car = [Driver createCar:@"Benz"];
car.strName = @"hohoho";
[car drive];
//司機(jī)開著奔馳出發(fā)
Car *car2 = [Driver createCar:@"Bmw"];
car2.strName = @"sss";
[car2 drive];
如果老板要坐奧迪券坞，同理鬓催。
這便是簡單工廠模式了。那么它帶了了什么好處呢恨锚？
首先宇驾，符合現(xiàn)實(shí)中的情況；而且客戶端免除了直接創(chuàng)建產(chǎn)品對象的責(zé)任猴伶，而僅僅負(fù)責(zé)“消費(fèi)”產(chǎn)品（正如暴發(fā)戶所為）课舍。
下面我們從開閉原則上來分析下簡單工廠模式。當(dāng)暴發(fā)戶增加了一輛車的時(shí)候他挎，只要符合抽象產(chǎn)品制定的合同筝尾，那么只要通知工廠類知道就可以被客戶使用了。（即創(chuàng)建一個(gè)新的車類办桨，繼承抽象產(chǎn)品Car）那么 對于產(chǎn)品部分來說筹淫，它是符合開閉原則的——對擴(kuò)展開放、對修改關(guān)閉呢撞；但是工廠類不太理想损姜，因?yàn)槊吭黾右惠v車，都要在工廠類中增加相應(yīng)的商業(yè)邏輯和判 斷邏輯狸相，這顯自然是違背開閉原則的薛匪。
而在實(shí)際應(yīng)用中，很可能產(chǎn)品是一個(gè)多層次的樹狀結(jié)構(gòu)脓鹃。就會導(dǎo)致很多問題了逸尖。
正如我前面提到的簡單工廠模式適用于業(yè)務(wù)簡單的情況下或者具體產(chǎn)品很少增加的情況。而對于復(fù)雜的業(yè)務(wù)環(huán)境可能不太適應(yīng)了瘸右。這就應(yīng)該由工廠方法模式來出場了＝扛！
四太颤、工廠方法模式
抽象工廠角色： 這是工廠方法模式的核心苞俘，它與應(yīng)用程序無關(guān)。是具體工廠角色必須實(shí)現(xiàn)的接口或者必須繼承的父類龄章。在java中它由抽象類或者接口來實(shí)現(xiàn)吃谣。
具體工廠角色：它含有和具體業(yè)務(wù)邏輯有關(guān)的代碼。由應(yīng)用程序調(diào)用以創(chuàng)建對應(yīng)的具體產(chǎn)品的對象做裙。在java中它由具體的類來實(shí)現(xiàn)岗憋。
抽象產(chǎn)品角色：它是具體產(chǎn)品繼承的父類或者是實(shí)現(xiàn)的接口。在java中一般有抽象類或者接口來實(shí)現(xiàn)锚贱。
具體產(chǎn)品角色：具體工廠角色所創(chuàng)建的對象就是此角色的實(shí)例仔戈。
來用類圖來清晰的表示下的它們之間的關(guān)系：
話說暴發(fā)戶生意越做越大，自己的愛車也越來越多。這可苦了那位司機(jī)師傅了监徘，什么車它都要記得晋修，維護(hù)，都要經(jīng)過他來使用凰盔！于是暴發(fā)戶同情他說：我給你分配幾個(gè)人手墓卦，你只管管好他們就行了！于是工廠方法模式的管理出現(xiàn)了廊蜒。代碼如下：
//抽象產(chǎn)品
@interface Car : NSObject
@property (nonatomic, copy) NSString *strName;
- (void)drive;
@end
#import "Car.h"
@implementation Car
- (void)drive {
}
@end
//具體產(chǎn)品
//奔馳
@interface Benz : Car
@end
@implementation Benz
- (void)drive {
NSLog(@"Benz Car:%@", self.strName);
}
@end
// 寶馬車
@interface Bmw : Car
@end
- (void)drive {
NSLog(@"BMW Car:%@",self.strName);
}
@end
//抽象工廠
@interface Driver : NSObject
+ (Car *)createCar:(NSString *)strCar;
@end
@implementation Driver
+ (Car *)createCar:(NSString *)strCar {
Car *c = nil;
if ([strCar isEqualToString:@"Bmw"]) {
c = [[Bmw alloc]init];
}
else if ([strCar isEqualToString:@"Benz"]) {
c = [[Benz alloc]init];
}
return c;
}
@end
//具體工廠（每個(gè)具體工廠負(fù)責(zé)一個(gè)具體產(chǎn)品）
@interface BenzDriver : Driver
@end
+ (Car *)createCar:(NSString *)strCar {
return [[Benz alloc]init];
}
@end
@interface BmwDriver : Driver
@end
@implementation BmwDriver
+ (Car *)createCar:(NSString *)strCar {
return [[Bmw alloc]init];
}
@end
//老板
Car *car = [BmwDriver createCar:@"Benz"];
car.strName = @"sdf";
[car drive];
使用開閉原則來分析下工廠方法模式趴拧。當(dāng)有新的產(chǎn)品（即暴發(fā)戶的汽車）產(chǎn)生時(shí)，只要按照抽象產(chǎn)品角色山叮、抽象工廠角色提供的合同來生成，那么就可以被客戶使用添履，而不必去修改任何已有的代碼屁倔。（即當(dāng)有新產(chǎn)品時(shí)，只要創(chuàng)建并基礎(chǔ)抽象產(chǎn)品暮胧；新建具體工廠繼承抽象工廠锐借；而不用修改任何一個(gè)類）工廠方法模式是完全符合開閉原則的！
使用工廠方法模式足以應(yīng)付我們可能遇到的大部分業(yè)務(wù)需求往衷。但是當(dāng)產(chǎn)品種類非常多時(shí)钞翔，就會出現(xiàn)大量的與之對應(yīng)的工廠類，這不應(yīng)該是我們所希望的席舍。所以我建議在這種情況下使用簡單工廠模式與工廠方法模式相結(jié)合的方式來減少工廠類：即對于產(chǎn)品樹上類似的種類（一般是樹的葉子中互為兄弟的）使用簡單工廠模式來實(shí)現(xiàn)布轿。
當(dāng)然特殊的情況，就要特殊對待了：對于系統(tǒng)中存在不同的產(chǎn)品樹来颤，而且產(chǎn)品樹上存在產(chǎn)品族（下一節(jié)將解釋這個(gè)名詞）汰扭。那么這種情況下就可能可以使用抽象工廠模式了。
五福铅、小結(jié)
讓我們來看看簡單工廠模式萝毛、工廠方法模式給我們的啟迪：
如果不使用工廠模式來實(shí)現(xiàn)我們的例子，也許代碼會減少很多——只需要實(shí)現(xiàn)已有的車滑黔，不使用多態(tài)笆包。但是在可維護(hù)性上，可擴(kuò)展性上是非常差的（你可以想象一下添加一輛車后要牽動的類）略荡。因此為了提高擴(kuò)展性和維護(hù)性庵佣，多寫些代碼是值得的。
六撞芍、抽象工廠模式
先來認(rèn)識下什么是產(chǎn)品族： 位于不同產(chǎn)品等級結(jié)構(gòu)中秧了，功能相關(guān)聯(lián)的產(chǎn)品組成的家族。
圖中的BmwCar和BenzCar就是兩個(gè)產(chǎn)品樹（產(chǎn)品層次結(jié)構(gòu)）序无；而如圖所示的BenzSportsCar和BmwSportsCar就是一個(gè)產(chǎn)品族验毡。他們都可以放到跑車家族中衡创，因此功能有所關(guān)聯(lián)。同理BmwBussinessCar和BenzBusinessCar也是一個(gè)產(chǎn)品族晶通。
可以這么說璃氢，它和工廠方法模式的區(qū)別就在于需要創(chuàng)建對象的復(fù)雜程度上。而且抽象工廠模式是三個(gè)里面最為抽象狮辽、最具一般性的一也。抽象工廠模式的用意為：給客戶端提供一個(gè)接口，可以創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對象喉脖。
而且使用抽象工廠模式還要滿足一下條件：
1.系統(tǒng)中有多個(gè)產(chǎn)品族椰苟，而系統(tǒng)一次只可能消費(fèi)其中一族產(chǎn)品
2.同屬于同一個(gè)產(chǎn)品族的產(chǎn)品以其使用。
來看看抽象工廠模式的各個(gè)角色（和工廠方法的如出一轍）：
抽象工廠角色： 這是工廠方法模式的核心树叽，它與應(yīng)用程序無關(guān)舆蝴。是具體工廠角色必須實(shí)現(xiàn)的接口或者必須繼承的父類。在java中它由抽象類或者接口來實(shí)現(xiàn)题诵。
具體工廠角色：它含有和具體業(yè)務(wù)邏輯有關(guān)的代碼襟企。由應(yīng)用程序調(diào)用以創(chuàng)建對應(yīng)的具體產(chǎn)品的對象逛裤。在java中它由具體的類來實(shí)現(xiàn)识椰。
抽象產(chǎn)品角色：它是具體產(chǎn)品繼承的父類或者是實(shí)現(xiàn)的接口涉兽。在java中一般有抽象類或者接口來實(shí)現(xiàn)。
具體產(chǎn)品角色：具體工廠角色所創(chuàng)建的對象就是此角色的實(shí)例草冈。在java中由具體的類來實(shí)現(xiàn)她奥。
//抽象產(chǎn)品（Bmw和Audi同理）
@interface Benz : Car
@end
@implementation Benz
- (void)drive {
NSLog(@"Benz Car:%@", self.strName);
}
@end
//具體產(chǎn)品（Bmw和Audi同理）
@interface BmwSportCar : Bmw
@end
@implementation BmwSportCar
- (void)drive {
NSLog(@"Bmw Sport Car:%@", self.strName);
}
@end
@interface Bmw : Car
@end
@implementation Bmw
- (void)drive {
NSLog(@"BMW Car:%@",self.strName);
}
@end
@interface BmwSportCar : Bmw
@end
@implementation BmwSportCar
- (void)drive {
NSLog(@"Bmw Sport Car:%@", self.strName);
}
@end
@interface BmwBusinessCar : Bmw
@end
@implementation BmwBusinessCar
- (void)drive {
NSLog(@"Bmw Business Car:%@", self.strName);
}
@end
//抽象工廠
@interface Driver : NSObject
#pragma mark - 抽象工廠模式
+ (Benz *)createBenzCar;
+ (Bmw *)createBmwCar;
@end
//具體工廠
@interface SportDriver : Driver
@end
@implementation SportDriver
+ (Car *)createBmwCar {
return [[BmwSportCar alloc]init];
}
+ (Car *)createBenzCar {
return [[BenzSportCar alloc]init];
}
@end
@interface BusinessDriver : Driver
@end
@implementation BusinessDriver
+ (Bmw *)createBmwCar {
return [[BmwBusinessCar alloc]init];
}
+ (Benz *)createBenzCar {
return [[BenzBusinessCar alloc]init];
}
@end
//老板
Car *businessCar = [BusinessDriver createBmwCar];
businessCar.strName = @"abc";
[businessCar drive];
Car *sportCar = [SportDriver createBenzCar];
sportCar.strName = @"def";
[sportCar drive];
其中：BenzSportCar和BenzBusinessCar屬于產(chǎn)品樹；同理BmwSportCar和BmwBusinessCar疲陕。而BenzSportCar和BmwSportCar和AudiSportCar屬于產(chǎn)品族方淤。
所以抽象工廠模式一般用于具有產(chǎn)品樹和產(chǎn)品族的場景下。
抽象工廠模式的缺點(diǎn)：如果需要增加新的產(chǎn)品樹蹄殃，那么就要新增三個(gè)產(chǎn)品類携茂，比如VolvoCar，VolvoSportCar,VolvoSportCar诅岩，并且要修改三個(gè)工廠類讳苦。這樣大批量的改動是很丑陋的做法。
所以可以用簡單工廠配合反射來改進(jìn)抽象工廠：
UML圖略吩谦。
收藏代碼 JAVA
abstract class BenzCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BenzSportCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzSportCar-----------------------");
}
}
class BenzBusinessCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzBusinessCar-----------------------");
}
}
abstract class BmwCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BmwSportCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwSportCar-----------------------");
}
}
class BmwBusinessCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwBusinessCar-----------------------");
}
}
abstract class AudiCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class AudiSportCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiSportCar-----------------------");
}
}
class AudiBusinessCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiBusinessCar-----------------------");
}
}
/**
* 簡單工廠通過反射改進(jìn)抽象工廠及其子工廠
* @author Administrator
*
*/
class Driver3{
public static BenzCar createBenzCar(String car) throws Exception {
return (BenzCar) Class.forName(car).newInstance();
}
public static BmwCar createBmwCar(String car) throws Exception {
return (BmwCar) Class.forName(car).newInstance();
}
public static AudiCar createAudiCar(String car) throws Exception {
return (AudiCar) Class.forName(car).newInstance();
}
}
//客戶端
public class SimpleAndAbstractFactory {
public static void main(String[] args) throws Exception {
AudiCar car = Driver3.createAudiCar("com.java.pattendesign.factory.AudiSportCar");
car.drive();
}
}
策略模式
從策略一詞來看,策略模式是種傾向于行為的模式.有點(diǎn)類似找仗時(shí)的做戰(zhàn)方案鸳谜，一般司令員在做戰(zhàn)前都會根據(jù)實(shí)際情況做出幾套不同的方案，如果當(dāng)時(shí)情況有變式廷，就會根據(jù)相應(yīng)的條件來判定用哪一套方案來替換原定方案咐扭。但無論如何替換，替換多少次，仗還是要打的蝗肪。
舉例：導(dǎo)出成EXCEL袜爪，WORD，PDF文件的功能薛闪，這三類導(dǎo)出雖然具體操作略有不同辛馆，但是大部分都相同。
策略模式與工廠模式從uml圖上來說豁延，基本一致昙篙。只是強(qiáng)調(diào)的封裝不同。我們以工廠模式和策略模式的比較來講解策略模式诱咏。
工廠模式我們可以做如下理解：假設(shè)有Audi的公司生產(chǎn)汽車苔可，它掌握一項(xiàng)核心的技術(shù)就是生產(chǎn)汽車，另一方面袋狞，它生產(chǎn)的汽車是有不同型號的硕蛹，并且在不同的生產(chǎn)線上進(jìn)行組裝。當(dāng)客戶通過銷售部門進(jìn)行預(yù)定后硕并，Audi公司將在指定的生產(chǎn)線上為客戶生產(chǎn)出它所需要的汽車。
策略(Strategy)模式在結(jié)構(gòu)上與工廠模式類似秧荆，唯一的區(qū)別是工廠模式實(shí)例化一個(gè)產(chǎn)品的操作是在服務(wù)端來做的倔毙，換句話說客戶端傳達(dá)給服務(wù)端的只是某種標(biāo)識，服務(wù)端根據(jù)該標(biāo)識實(shí)例化一個(gè)對象乙濒。而策略模式的客戶端傳達(dá)給服務(wù)端的是一個(gè)實(shí)例陕赃，服務(wù)端只是將該實(shí)例拿過去在服務(wù)端的環(huán)境里執(zhí)行該實(shí)例的方法。這就好比一個(gè)對汽車不甚了解的人去買車颁股，他在那一比劃么库，說要什么什么樣的，銷售部門根據(jù)他的這個(gè)“比劃”來形成一份訂單甘有，這就是工廠模式下的工作方式诉儒。而策略模式下那個(gè)顧客就是個(gè)行家，他自己給出了訂單的詳細(xì)信息亏掀，銷售部門只是轉(zhuǎn)了一下手就交給生產(chǎn)部門去做了忱反。通過兩相對比，我們不難發(fā)現(xiàn)滤愕，采用工廠模式必須提供足夠靈活的銷售部門温算，如果用戶有了新的需求，銷售部門必須馬上意識到這樣才可以做出合適的訂單间影。所以倘一款新車出來了注竿，生產(chǎn)部門和銷售部門都需要更新，對顧客來說也需要更新對新車的描述所以需要改動的地方有三處。而策略模式中的銷售部門工作比較固定巩割，它只負(fù)責(zé)接受訂單并執(zhí)行特定的幾個(gè)操作裙顽。當(dāng)一款新車出來時(shí)，只需要對服務(wù)端的生產(chǎn)部門和客戶端的代碼進(jìn)行更新喂分，而不需要更新銷售部門的代碼锦庸。
技術(shù)支持： 簡單工廠和策略的基礎(chǔ)都是因?yàn)槊嫦驅(qū)ο蟮姆庋b與多態(tài)。他們實(shí)現(xiàn)的思想都是先設(shè)定一個(gè)抽象的模型并從該模型派生出符合不同客戶需求的各種方法蒲祈，并加以封裝甘萧。
工廠模式和策略模式的區(qū)別在于實(shí)例化一個(gè)對象的位置不同，對工廠模式而言梆掸，實(shí)例化對象是放在服務(wù)端的扬卷，即放在了工廠類里面；
而策略模式實(shí)例化對象的操作在客戶端酸钦，服務(wù)端的“銷售部門”只負(fù)責(zé)傳遞該對象怪得，并在服務(wù)端的環(huán)境里執(zhí)行特定的操作。卑硫。徒恋。
工廠模式要求服務(wù)端的銷售部門足夠靈敏，而策略模式由于對策略進(jìn)行了封裝欢伏，所以他的銷售部門比較傻入挣，需要客戶提供足夠能區(qū)分使用哪種策略的參數(shù)，而這最好的就是該策略的實(shí)例了硝拧。
//抽象產(chǎn)品 JAVA
abstract class AudiCar{
private String name;
public abstract void makeCar();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產(chǎn)品
class AudiA6 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class AudiA4 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//銷售部門----服務(wù)端
class CarContext {
AudiCar audiCar = null;
public CarContext(AudiCar audiCar) {
this.audiCar = audiCar;
}
public void orderCar(){
this.audiCar.makeCar();
}
}
//客戶----客戶端（這個(gè)客戶是內(nèi)行径筏，什么都懂，他說我要A6障陶，銷售部門立刻給他a6滋恬，所以銷售部門不用很懂）
public class SimplyFactoryAndStrategy2 {
public static void main(String[] args) throws IOException {
//客戶說我要什么什么樣子的車子，銷售人員才知道他要什么樣子的車子
AudiCar car = new AudiA6();
car.setName("a6");
CarContext context = new CarContext(car);
context.orderCar();
}
}
//工廠模式---與上面的策略模式比較
//抽象產(chǎn)品
abstract class AudiCar{
private String name;
public abstract void makeCar();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產(chǎn)品
class AudiA6 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class AudiA4 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//簡單工廠---銷售部門----服務(wù)端
class CarFactroy{
public static AudiCar createCar(String car){
AudiCar c = null;
if("A6".equalsIgnoreCase(car))
c = new AudiA6();
else if("A4".equalsIgnoreCase(car))
c = new AudiA4();
return c;
}
}
//客戶----客戶端（這個(gè)客戶是外行抱究，什么都不懂恢氯，只要隨便描述下車，銷售部門才能知道他要那款車媳维，所以銷售部門比較牛）
public class SimplyFactoryAndStrategy {
public static void main(String[] args) throws IOException {
System.out.print("請輸入您要坐的車：（A6酿雪、A4）");
String carName = new BufferedReader(new InputStreamReader(System.in)).readLine();
//客戶說我要什么什么樣子的車子，銷售人員才知道他要什么樣子的車子
AudiCar car = CarFactroy.createCar(carName);
car.setName(carName);
car.makeCar();
}
}
策略模式的優(yōu)缺點(diǎn)
策略模式的主要優(yōu)點(diǎn)有：
策略類之間可以自由切換侄刽，由于策略類實(shí)現(xiàn)自同一個(gè)抽象指黎，所以他們之間可以自由切換。
易于擴(kuò)展州丹，增加一個(gè)新的策略對策略模式來說非常容易醋安，基本上可以在不改變原有代碼的基礎(chǔ)上進(jìn)行擴(kuò)展杂彭。
避免使用多重條件，如果不使用策略模式吓揪，對于所有的算法亲怠，必須使用條件語句進(jìn)行連接，通過條件判斷來決定使用哪一種算法柠辞，在上一篇文章中我們已經(jīng)提到团秽，使用多重條件判斷是非常不容易維護(hù)的。
策略模式的缺點(diǎn)主要有兩個(gè)：
維護(hù)各個(gè)策略類會給開發(fā)帶來額外開銷叭首，可能大家在這方面都有經(jīng)驗(yàn)：一般來說习勤，策略類的數(shù)量超過5個(gè)，就比較令人頭疼了焙格。
必須對 客戶端（調(diào)用者）暴露所有的策略類图毕，因?yàn)槭褂媚姆N策略是由客戶端來決定的，因此眷唉，客戶端應(yīng)該知道有什么策略予颤，并且了解各種策略之間的區(qū)別，否則冬阳，后果很嚴(yán) 重蛤虐。例如，有一個(gè)排序算法的策略模式肝陪，提供了快速排序笆焰、冒泡排序、選擇排序這三種算法见坑，客戶端在使用這些算法之前，是不是先要明白這三種算法的適用情況捏检？ 再比如荞驴，客戶端要使用一個(gè)容器，有鏈表實(shí)現(xiàn)的贯城，也有數(shù)組實(shí)現(xiàn)的熊楼，客戶端是不是也要明白鏈表和數(shù)組有什么區(qū)別？就這一點(diǎn)來說是有悖于迪米特法則的能犯。
適用場景
做面向?qū)ο笤O(shè)計(jì)的鲫骗，對策略模式一定很熟悉，因?yàn)樗鼘?shí)質(zhì)上就是面向?qū)ο笾械睦^承和多態(tài)踩晶，在看完策略模式的通用代碼后执泰，我想，即使之前從來沒有聽說過策略模式渡蜻，在開發(fā)過程中也一定使用過它吧术吝？至少在在以下兩種情況下计济，大家可以考慮使用策略模式，
幾個(gè)類的主要邏輯相同排苍，只在部分邏輯的算法和行為上稍有區(qū)別的情況沦寂。
有幾種相似的行為，或者說算法淘衙，客戶端需要動態(tài)地決定使用哪一種传藏，那么可以使用策略模式，將這些算法封裝起來供客戶端調(diào)用彤守。
策略模式是一種簡單常用的模式毯侦，我們在進(jìn)行開發(fā)的時(shí)候，會經(jīng)常有意無意地使用它遗增，一般來說叫惊，策略模式不會單獨(dú)使用，跟模版方法模式做修、工廠模式等混合使用的情況比較多霍狰。
大粒度的 if --else if...可以使用 工廠+策略模式搞定。
