設計模式的原則:針對借口編程
原廠模式的作用:
A.應用程式的設計中把對象的的建立集中在一個地方建立或者統一由某類來管理(spring)
B.在不改動應用程式的基礎上可以直接添加對象,同時也利於對象的維護。
原廠模式的種類:
A.簡單工廠
B.Factory 方法
C.抽象工廠
楔子:
話說東北某老闆家裡有三輛車,平治,寶馬,藍博基尼,雇了一名有經驗的司機,不同的場合他會吩咐司機開不同的車應酬。
簡單工廠:
abstruact:
package com.product.abstruct;
public interface Car {
public void drive();//車是用來開的,所以得有個發動機
}
implements:
package com.product.implement;
import com.product.abstruct.Car;
public class Audi implements Car {
public void drive(){//寶馬他也是車不是馬,也得有發動機
// TODO Auto-generated method stub
System.out.println("yes,today wo are driving Audi。。。。");
}
}
package com.product.implement;
import com.product.abstruct.Car;
public class Benz implements Car {
public void drive(){//奧迪他也是車不是迪奧,也得有發動機
// TODO Auto-generated method stub
System.out.println("yes,today wo are driving Benz。。。。");
System.out.println("老闆,一些按照您的吩咐....");
}
}
======蘭博基尼省======
Factory類:
factory類是一個管理類,是汽車的直接負責人,這個人就是老闆的司機;
package com.product.factory;
import com.product.abstruct.Car;
import com.product.implement.Audi;
import com.product.implement.Benz;
public class Driver {
public static Car driveCar(String carName) throws Exception{
if(carName.equalsIgnoreCase("Benz")){
return new Benz();
}
if(carName.equalsIgnoreCase("bmw")){
return new Bwm();
}
return new Audi();
}
}
某一天老闆要去英格蘭觀看利物浦主場對陣維拉的比賽,需要開寶馬去機場,於是把司機叫來,讓他下午2點開寶馬來接他。。。
package com.product.test;
import com.product.abstruct.Car;
import com.product.factory.Driver;
public class Test {
public static void main(String[] args) throws Exception{
//tell the driver which car wo drive todaty wo will to Amsterdam
Car car = Driver.driveCar("Benz");//讓司機開車過來接
//Mrs wang go
car.drive();//一鍵啟動
}
}
Factory 方法:
隨著老闆的生意越做越大,越來越有錢,於是乎他有買了幾輛跑車----法拉利、保時捷、捷豹三部座駕,由於車兩增加了,所有的汽車都要有老司機一個人管理,年檢、保險、罰單、洗車,老司機一個人實在吃不消,而且老闆會吩咐老司機從周一到周六要開不同款式的車外出,這個時候老司機就不得不記住老闆哪天需要開哪輛車外出,於是乎給老闆提議:給每台車都聘請一個司機,每輛汽車都有一個專門的人員負責,需要外出的時候招呼我一聲,我就會派相應的人員過來接老闆,老闆毫不猶豫的說:就這麼辦.......
抽象汽車類:
package com.product.car.abstruct;
public interface Car {
public void drive();
}
奧迪汽車:
package com.product.car.implement;
import com.product.car.abstruct.Car;
public class AudiDriver implements Car {
public void drive() {
System.out.println("想當官四個圈");
}
}
平治汽車:
package com.product.car.implement;
import com.product.car.abstruct.Car;
public class AudiDriver implements Car {
public void drive() {
System.out.println("想當官四個圈");
}
}
======省略其他汽車======
汽車總管(老司機)
package com.product.car.manager;
import com.product.car.abstruct.Car;
public interface CarManager {
public Car driveCar();
}
新招聘的奧迪司機:
package com.product.car.managerImpl;
import com.product.car.abstruct.Car;
import com.product.car.implement.AudiDriver;
import com.product.car.manager.CarManager;
public class AudiManager implements CarManager {
public Car driveCar() {
return new AudiDriver();
}
}
新招聘的平治司機:
package com.product.car.managerImpl;
import com.product.car.abstruct.Car;
import com.product.car.implement.BenzDriver;
import com.product.car.manager.CarManager;
public class BenzManager implements CarManager {
public Car driveCar(){
return new BenzDriver();
}
}
某天老闆想去利物浦:
package com.product.test;
import com.product.car.abstruct.Car;
import com.product.car.implement.BenzDriver;
import com.product.car.manager.CarManager;
public class Test {
public static void main(String[] args) throws Exception{
//找到汽車主管,告訴他今天我想開寶馬去看利物浦對陣維拉的比賽
CarManager carManager = (CarManager) new BenzDriver();
//負責寶馬汽車的司機接到管家的電話,給寶馬加滿油,寶馬來嘍
Car driveCar = carManager.driveCar();
//飛奔利物浦
driveCar.drive();
}
}
以上就是原廠模式中的簡單工廠,Factory 方法,先來比較一下這兩種模式的卻別以及各自的優勢所在,
程式設計角度:
a.簡單工廠沒有抽象類別,只有一個工廠類,把需要建立對象的參數傳遞過來,由工廠類統一建立
b.定義一個建立產品對象的介面,該介面扮演這核心的角色,他只需要定義子類必須實現的方法即可,將對象交給對象本身來建立
優勢劣勢:
a.相對簡單工廠Factory 方法要更加的抽象,這樣做的好處在於不改變工廠角色的基礎上(不辭退老司機或者給他調崗)可以很輕鬆的增加新的成員(招聘更多的司機);
b.簡單工廠的優勢在於簡單,僅僅是根據參數來建立相應對象即可,但劣勢也相當明顯,所有的對象都集中在該類中建立,所建立的對象只能是事先就知道的(忽然有一天老闆買來一輛手動擋捷達,老闆就必須通知老司機,我買了一輛捷達,在X放著);成員對象的添加會引起核心類增加方法,違反高內聚,當系統中的具體產品類不斷增多時候,可能會出現要求工廠類根據不同條件建立不同執行個體的需求.這種對條件的判斷和對具體產品類型的判斷交錯在一起,很難避免模組功能的蔓延,對系統的維護和擴充非常不利;
接下來時原廠模式的應用,程式設計中我們如何合理的應用工廠設計模式呢
a.對於某個產品,調用者清楚地知道應該使用哪個具體工廠服務,執行個體化該具體工廠,生產出具體的產品來。Java Collection中的iterator() 方法即屬於這種情況。
b.只是需要一種產品,而不想知道也不需要知道究竟是哪個工廠為生產的,即最終選用哪個具體工廠的決定權在生產者一方,它們根據當前系統的情況來執行個體化一個具體的工廠返回給使用者,而這個決策過程這對於使用者來說是透明的。