工廠模式

工廠模式是一種創(chuàng)建型設(shè)計(jì)模式，它提供了一種創(chuàng)建對(duì)象的最佳實(shí)踐，旨在將對(duì)象的創(chuàng)建過(guò)程與使用過(guò)程分離，以提高代碼的靈活性、可維護(hù)性和可擴(kuò)展性。工廠模式主要有以下三種類(lèi)型：

簡(jiǎn)單工廠模式（Simple Factory）：
簡(jiǎn)單工廠不是一個(gè)GoF（設(shè)計(jì)模式的四人幫， Gang of Four）正式提出的設(shè)計(jì)模式，但它常被認(rèn)為是工廠方法模式的簡(jiǎn)化版本。
提供一個(gè)統(tǒng)一的接口用于創(chuàng)建相關(guān)或依賴(lài)對(duì)象，而不需要暴露創(chuàng)建邏輯給客戶(hù)端，也不需要客戶(hù)端知道具體產(chǎn)品的類(lèi)。
適用于產(chǎn)品種類(lèi)不多，且不會(huì)頻繁新增產(chǎn)品種類(lèi)的情況。

工廠方法模式 （Factory Method）：
屬于GoF提出的23種設(shè)計(jì)模式之一，屬于創(chuàng)建型模式。
定義了一個(gè)用于創(chuàng)建對(duì)象的接口，但讓子類(lèi)決定實(shí)例化哪一個(gè)類(lèi)。工廠方法使一個(gè)類(lèi)的實(shí)例化延遲到其子類(lèi)。
提高了系統(tǒng)的擴(kuò)展性，當(dāng)需要添加新產(chǎn)品時(shí)，只需要添加相應(yīng)的產(chǎn)品類(lèi)和對(duì)應(yīng)的工廠子類(lèi)即可，無(wú)需修改現(xiàn)有代碼。

抽象工廠模式
同樣是GoF設(shè)計(jì)模式之一，也是創(chuàng)建型模式。
提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴(lài)對(duì)象的接口，而無(wú)需指定它們具體的類(lèi)。
適用于系統(tǒng)需要獨(dú)立于產(chǎn)品的創(chuàng)建、組合和表示的情況下，強(qiáng)調(diào)的是“系列”對(duì)象的創(chuàng)建，而不是單一產(chǎn)品的創(chuàng)建。
這三種模式從簡(jiǎn)單到復(fù)雜，分別解決了不同復(fù)雜度的創(chuàng)建需求，提高了軟件的結(jié)構(gòu)靈活性和可維護(hù)性。在選擇使用哪種工廠模式時(shí)，應(yīng)根據(jù)項(xiàng)目的具體需求和未來(lái)可能的變化來(lái)決定。

1.簡(jiǎn)單工廠模式

優(yōu)點(diǎn) :

1. 代碼解耦：客戶(hù)端不需要知道具體產(chǎn)品的創(chuàng)建細(xì)節(jié)，降低了模塊間的耦合度。
2. 易于使用：客戶(hù)端只需調(diào)用一個(gè)方法就可以創(chuàng)建對(duì)象，使得對(duì)象的創(chuàng)建更加簡(jiǎn)單直觀。

缺點(diǎn):

1. 違背開(kāi)閉原則：一旦需要添加新產(chǎn)品，就需要修改工廠類(lèi)的代碼，這增加了系統(tǒng)的復(fù)雜性和維護(hù)難度。
2. 不靈活：對(duì)于產(chǎn)品類(lèi)型較多的情況，工廠類(lèi)可能會(huì)變得龐大且難以管理。
   難以支持多態(tài)：由于工廠類(lèi)集中創(chuàng)建所有產(chǎn)品，難以利用多態(tài)來(lái)減少代碼重復(fù)。

簡(jiǎn)單工廠模式示例

// 產(chǎn)品接口
interface Product {void show();
}// 具體產(chǎn)品A
class ConcreteProductA implements Product {@Overridepublic void show() {System.out.println("ConcreteProductA");}
}// 具體產(chǎn)品B
class ConcreteProductB implements Product {@Overridepublic void show() {System.out.println("ConcreteProductB");}
}// 簡(jiǎn)單工廠
class SimpleFactory {public static Product createProduct(String type) {if ("A".equals(type)) {return new ConcreteProductA();} else if ("B".equals(type)) {return new ConcreteProductB();}throw new IllegalArgumentException("Invalid type");}
}public class SimpleFactoryDemo {public static void main(String[] args) {Product productA = SimpleFactory.createProduct("A");productA.show();Product productB = SimpleFactory.createProduct("B");productB.show();}
}

2.工廠方法模式

優(yōu)點(diǎn):

1. 遵循開(kāi)閉原則：新增產(chǎn)品時(shí)，只需要增加對(duì)應(yīng)的產(chǎn)品類(lèi)和工廠子類(lèi)，無(wú)需修改已有代碼。
2. 高內(nèi)聚低耦合：每個(gè)工廠子類(lèi)負(fù)責(zé)一種產(chǎn)品的創(chuàng)建，職責(zé)清晰，易于維護(hù)和擴(kuò)展。
3. 支持多態(tài)：通過(guò)面向接口編程，可以充分利用多態(tài)特性，提高代碼的靈活性。

缺點(diǎn):

1. 類(lèi)膨脹：隨著產(chǎn)品種類(lèi)的增加，需要?jiǎng)?chuàng)建大量的工廠類(lèi)和產(chǎn)品類(lèi)，可能會(huì)導(dǎo)致類(lèi)的數(shù)量急劇增加。
2. 客戶(hù)需要知道具體工廠：客戶(hù)端需要決定使用哪個(gè)工廠來(lái)創(chuàng)建產(chǎn)品，這在某些情況下可能降低代碼的透明度。

工廠方法模式示例

// 抽象工廠
interface Factory {Product createProduct();
}// 具體工廠A
class ConcreteFactoryA implements Factory {@Overridepublic Product createProduct() {return new ConcreteProductA();}
}// 具體工廠B
class ConcreteFactoryB implements Factory {@Overridepublic Product createProduct() {return new ConcreteProductB();}
}public class FactoryMethodDemo {public static void main(String[] args) {Factory factoryA = new ConcreteFactoryA();Product productA = factoryA.createProduct();productA.show();Factory factoryB = new ConcreteFactoryB();Product productB = factoryB.createProduct();productB.show();}
}

3.抽象工廠模式

優(yōu)點(diǎn):

1. 系列產(chǎn)品的創(chuàng)建：非常適合創(chuàng)建一系列相關(guān)或相互依賴(lài)的對(duì)象，保持產(chǎn)品族內(nèi)的產(chǎn)品一致性。
2. 高度封裝：通過(guò)抽象工廠，可以隱藏具體產(chǎn)品的創(chuàng)建細(xì)節(jié)，提供一個(gè)高層的接口給客戶(hù)端使用。
3. 易于擴(kuò)展：增加新的產(chǎn)品族時(shí)，只需要增加一個(gè)新的抽象工廠類(lèi)和具體工廠類(lèi)，不影響現(xiàn)有的客戶(hù)代碼。

缺點(diǎn):

1. 復(fù)雜度提高：抽象工廠模式的結(jié)構(gòu)較為復(fù)雜，理解和維護(hù)成本相對(duì)較高。
2. 產(chǎn)品族擴(kuò)展困難：一旦定義好抽象工廠和產(chǎn)品族，向產(chǎn)品族中添加新的產(chǎn)品比較困難，可能需要修改抽象工廠的接口。
   抽象工廠模式示例
   假設(shè)我們有兩個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)：操作系統(tǒng)和瀏覽器。

// 抽象產(chǎn)品：操作系統(tǒng)
interface OperatingSystem {void showOS();
}// 具體產(chǎn)品：Windows操作系統(tǒng)
class Windows implements OperatingSystem {@Overridepublic void showOS() {System.out.println("Windows OS");}
}// 具體產(chǎn)品：Mac操作系統(tǒng)
class Mac implements OperatingSystem {@Overridepublic void showOS() {System.out.println("Mac OS");}
}// 抽象產(chǎn)品：瀏覽器
interface Browser {void showBrowser();
}// 具體產(chǎn)品：Chrome瀏覽器
class Chrome implements Browser {@Overridepublic void showBrowser() {System.out.println("Chrome");}
}// 具體產(chǎn)品：Safari瀏覽器
class Safari implements Browser {@Overridepublic void showBrowser() {System.out.println("Safari");}
}// 抽象工廠
interface AbstractFactory {OperatingSystem createOperatingSystem();Browser createBrowser();
}// 具體工廠：Windows產(chǎn)品族
class WindowsFactory implements AbstractFactory {@Overridepublic OperatingSystem createOperatingSystem() {return new Windows();}@Overridepublic Browser createBrowser() {return new Chrome();}
}// 具體工廠：Mac產(chǎn)品族
class MacFactory implements AbstractFactory {@Overridepublic OperatingSystem createOperatingSystem() {return new Mac();}@Overridepublic Browser createBrowser() {return new Safari();}
}public class AbstractFactoryDemo {public static void main(String[] args) {AbstractFactory windowsFactory = new WindowsFactory();windowsFactory.createOperatingSystem().showOS();windowsFactory.createBrowser().showBrowser();AbstractFactory macFactory = new MacFactory();macFactory.createOperatingSystem().showOS();macFactory.createBrowser().showBrowser();}
}

每種工廠模式都有其適用場(chǎng)景和局限性，選擇合適的模式需基于項(xiàng)目的需求、擴(kuò)展性和維護(hù)性等因素綜合考慮。

策略模式

策略模式（Strategy Pattern）是一種行為設(shè)計(jì)模式，它定義了一系列算法，并將每一個(gè)算法封裝起來(lái)，使它們可以互相替換。策略模式讓算法的變化獨(dú)立于使用算法的客戶(hù)，使代碼結(jié)構(gòu)更加靈活，易于擴(kuò)展。
優(yōu)點(diǎn)

1. 算法的封裝與互換：策略模式將算法封裝在獨(dú)立的類(lèi)中，使得算法的變更不會(huì)影響到使用算法的客戶(hù)類(lèi)，同時(shí)也方便在運(yùn)行時(shí)切換算法。
2. 遵循開(kāi)閉原則：新增策略時(shí)，只需要增加新的策略類(lèi)，不需要修改原有代碼，增強(qiáng)了系統(tǒng)的可擴(kuò)展性。
   簡(jiǎn)化復(fù)雜條件判斷：可以消除大量使用條件語(yǔ)句（如if-else或switch-case）來(lái)選擇算法的代碼，使得代碼更加清晰和易于維護(hù)。
3. 提高代碼復(fù)用性：相同的行為可以被多個(gè)上下文重用，減少了代碼冗余。

缺點(diǎn)
4. 客戶(hù)端必須了解策略：客戶(hù)端需要知道所有策略類(lèi)的存在，并決定使用哪個(gè)策略，這可能會(huì)增加客戶(hù)端的復(fù)雜度。
5. 類(lèi)數(shù)量增加：每增加一個(gè)策略，就需要增加一個(gè)類(lèi)，可能導(dǎo)致類(lèi)的數(shù)量膨脹。
6. 過(guò)度設(shè)計(jì)風(fēng)險(xiǎn)：對(duì)于簡(jiǎn)單的場(chǎng)景，使用策略模式可能會(huì)導(dǎo)致設(shè)計(jì)過(guò)度復(fù)雜。

代碼示例
假設(shè)我們有一個(gè)購(gòu)物車(chē)系統(tǒng)，需要根據(jù)不同的支付策略計(jì)算訂單的總金額，比如正常價(jià)格、會(huì)員折扣價(jià)、促銷(xiāo)價(jià)等。

// 策略接口
interface PaymentStrategy {double calculateTotal(double amount);
}// 具體策略類(lèi)：正常支付
class NormalPayment implements PaymentStrategy {@Overridepublic double calculateTotal(double amount) {return amount;}
}// 具體策略類(lèi)：會(huì)員折扣支付
class MemberDiscountPayment implements PaymentStrategy {@Overridepublic double calculateTotal(double amount) {return amount * 0.9; // 會(huì)員享有10%折扣}
}// 具體策略類(lèi)：促銷(xiāo)支付
class PromotionPayment implements PaymentStrategy {@Overridepublic double calculateTotal(double amount) {return amount * 0.8; // 促銷(xiāo)活動(dòng)打8折}
}// 環(huán)境類(lèi)（Context），使用策略的類(lèi)
class ShoppingCart {private PaymentStrategy strategy;public void setPaymentStrategy(PaymentStrategy strategy) {this.strategy = strategy;}public double calculateTotal(double amount) {return strategy.calculateTotal(amount);}
}public class StrategyPatternDemo {public static void main(String[] args) {ShoppingCart cart = new ShoppingCart();// 使用會(huì)員折扣策略cart.setPaymentStrategy(new MemberDiscountPayment());System.out.println("會(huì)員折扣總價(jià)：" + cart.calculateTotal(100));// 切換到促銷(xiāo)策略cart.setPaymentStrategy(new PromotionPayment());System.out.println("促銷(xiāo)活動(dòng)總價(jià)：" + cart.calculateTotal(100));// 使用正常支付策略cart.setPaymentStrategy(new NormalPayment());System.out.println("正常支付總價(jià)：" + cart.calculateTotal(100));}
}

責(zé)任鏈模式概述

責(zé)任鏈模式（Chain of Responsibility Pattern）是一種行為設(shè)計(jì)模式，它允許將請(qǐng)求沿著處理者鏈進(jìn)行傳遞，直到找到能夠處理該請(qǐng)求的處理者。每個(gè)處理者都包含對(duì)下個(gè)處理者的引用，如果一個(gè)處理者不能處理請(qǐng)求，則會(huì)將請(qǐng)求傳遞給鏈中的下一個(gè)處理者。這樣，多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免了請(qǐng)求發(fā)送者與接收者之間的耦合。
優(yōu)點(diǎn)

1. 解耦：發(fā)送請(qǐng)求的對(duì)象與處理請(qǐng)求的對(duì)象解耦，兩者不直接關(guān)聯(lián)，易于擴(kuò)展和維護(hù)。
2. 簡(jiǎn)化對(duì)象：每個(gè)處理者只需關(guān)注自己的處理邏輯，不需要知道完整的請(qǐng)求處理鏈。
3. 靈活性：可以通過(guò)添加新的處理者或者改變處理者的順序來(lái)動(dòng)態(tài)地調(diào)整處理流程，而無(wú)需修改已有代碼。

缺點(diǎn)

1. 不能保證請(qǐng)求被處理：如果鏈中的所有處理者都不處理請(qǐng)求，請(qǐng)求可能會(huì)被忽略。
2. 調(diào)試?yán)щy：因?yàn)檎?qǐng)求的處理路徑可能較為復(fù)雜，定位問(wèn)題時(shí)可能需要跟蹤整個(gè)鏈。
3. 性能問(wèn)題：鏈過(guò)長(zhǎng)時(shí)，請(qǐng)求的處理可能會(huì)涉及多個(gè)對(duì)象，影響系統(tǒng)性能。
4. 職責(zé)鏈構(gòu)建復(fù)雜性：客戶(hù)端需要正確構(gòu)建職責(zé)鏈，不當(dāng)?shù)呐渲每赡軐?dǎo)致循環(huán)調(diào)用或請(qǐng)求丟失。

代碼示例
假設(shè)我們有一個(gè)簡(jiǎn)單的審批系統(tǒng)，需要根據(jù)不同的金額級(jí)別由不同級(jí)別的經(jīng)理進(jìn)行審批。

// 定義處理請(qǐng)求的接口
interface Approver {void setNextApprover(Approver nextApprover);void processRequest(int amount);
}// 具體處理者：部門(mén)經(jīng)理
class DepartmentManager implements Approver {private Approver nextApprover;@Overridepublic void setNextApprover(Approver nextApprover) {this.nextApprover = nextApprover;}@Overridepublic void processRequest(int amount) {if (amount <= 5000) {System.out.println("部門(mén)經(jīng)理批準(zhǔn)了 " + amount + " 元的請(qǐng)求。");} else if (nextApprover != null) {nextApprover.processRequest(amount);}}
}// 具體處理者：總經(jīng)理
class GeneralManager implements Approver {private Approver nextApprover;@Overridepublic void setNextApprover(Approver nextApprover) {this.nextApprover = nextApprover;}@Overridepublic void processRequest(int amount) {if (amount <= 10000) {System.out.println("總經(jīng)理批準(zhǔn)了 " + amount + " 元的請(qǐng)求。");} else if (nextApprover != null) {nextApprover.processRequest(amount);}}
}// 客戶(hù)端代碼
public class ChainOfResponsibilityDemo {public static void main(String[] args) {Approver departmentManager = new DepartmentManager();Approver generalManager = new GeneralManager();// 構(gòu)建責(zé)任鏈departmentManager.setNextApprover(generalManager);// 提交請(qǐng)求departmentManager.processRequest(3000);  // 部門(mén)經(jīng)理處理departmentManager.processRequest(8000);  // 總經(jīng)理處理departmentManager.processRequest(12000); // 未處理，超出了所有處理者的權(quán)限}
}

模板方法模式概述

模板方法模式（Template Method Pattern）是一種行為設(shè)計(jì)模式，它定義了一個(gè)操作中的算法骨架，而將一些步驟延遲到子類(lèi)中實(shí)現(xiàn)。模板方法使得子類(lèi)可以重新定義算法的某些步驟，而不改變算法的結(jié)構(gòu)。
優(yōu)點(diǎn)

1. 代碼復(fù)用：通過(guò)將不變部分的代碼放在父類(lèi)的模板方法中，減少代碼重復(fù)。
2. 易于擴(kuò)展：子類(lèi)可以覆蓋父類(lèi)中的抽象方法，以適應(yīng)不同的需求，增加新的行為。
3. 行為控制：父類(lèi)中的模板方法控制了算法的整體流程，子類(lèi)則專(zhuān)注于實(shí)現(xiàn)細(xì)節(jié)，有助于保持代碼結(jié)構(gòu)清晰。

缺點(diǎn)

1. 類(lèi)膨脹：如果算法中有很多可變步驟，會(huì)導(dǎo)致子類(lèi)數(shù)量增加，系統(tǒng)復(fù)雜度可能會(huì)上升。
2. 難以理解：對(duì)于新加入項(xiàng)目的成員來(lái)說(shuō)，理解模板方法模式的結(jié)構(gòu)和意圖可能需要更多時(shí)間。
3. 過(guò)度設(shè)計(jì)：對(duì)于簡(jiǎn)單的操作，使用模板方法模式可能會(huì)造成不必要的復(fù)雜度。
   代碼舉例
   正在開(kāi)發(fā)一個(gè)文件處理框架，該框架需要支持多種文件格式（如TXT、PDF、JPEG）的讀取和保存操作。雖然每種文件的讀寫(xiě)邏輯不同，但整體流程（打開(kāi)文件、讀取數(shù)據(jù)、處理數(shù)據(jù)、保存數(shù)據(jù)、關(guān)閉文件）是相似的。

// 抽象類(lèi)，定義文件處理的模板方法
abstract class FileProcessor {public final void processFile(String filePath) {openFile(filePath);readFile();processData();writeFile();closeFile();}abstract void openFile(String filePath); // 抽象方法，由子類(lèi)實(shí)現(xiàn)打開(kāi)文件abstract void readFile(); // 抽象方法，由子類(lèi)實(shí)現(xiàn)讀取文件內(nèi)容abstract void processData(); // 抽象方法，由子類(lèi)實(shí)現(xiàn)數(shù)據(jù)處理邏輯abstract void writeFile(); // 抽象方法，由子類(lèi)實(shí)現(xiàn)寫(xiě)入文件abstract void closeFile(); // 抽象方法，由子類(lèi)實(shí)現(xiàn)關(guān)閉文件
}// 具體實(shí)現(xiàn)類(lèi)，處理TXT文件
class TXTFileProcessor extends FileProcessor {@Overridevoid openFile(String filePath) {System.out.println("Opening TXT file: " + filePath);}@Overridevoid readFile() {System.out.println("Reading TXT content");}@Overridevoid processData() {System.out.println("Processing TXT data");}@Overridevoid writeFile() {System.out.println("Writing processed TXT data back to file");}@Overridevoid closeFile() {System.out.println("Closing TXT file");}
}// 具體實(shí)現(xiàn)類(lèi)，處理PDF文件
class PDFFileProcessor extends FileProcessor {@Overridevoid openFile(String filePath) {System.out.println("Opening PDF file: " + filePath);}@Overridevoid readFile() {System.out.println("Reading PDF content");}@Overridevoid processData() {System.out.println("Processing PDF data");}@Overridevoid writeFile() {System.out.println("Writing processed PDF data back to file");}@Overridevoid closeFile() {System.out.println("Closing PDF file");}
}public class FileProcessingDemo {public static void main(String[] args) {FileProcessor txtProcessor = new TXTFileProcessor();FileProcessor pdfProcessor = new PDFFileProcessor();txtProcessor.processFile("sample.txt"); // 處理TXT文件pdfProcessor.processFile("document.pdf"); // 處理PDF文件}
}

在這個(gè)例子中，FileProcessor類(lèi)定義了處理文件的模板方法，包括打開(kāi)文件、讀取文件、處理數(shù)據(jù)、寫(xiě)入文件和關(guān)閉文件的一系列步驟。TXTFileProcessor和PDFFileProcessor類(lèi)作為具體實(shí)現(xiàn)，分別覆蓋了這些抽象方法以實(shí)現(xiàn)特定文件格式的處理邏輯。這種設(shè)計(jì)使得新增其他文件類(lèi)型的支持變得非常簡(jiǎn)單，只需要?jiǎng)?chuàng)建一個(gè)新的子類(lèi)并實(shí)現(xiàn)相應(yīng)的抽象方法即可。

單例模式概述

單例模式（Singleton Pattern）是一種創(chuàng)建型設(shè)計(jì)模式，它確保一個(gè)類(lèi)在整個(gè)應(yīng)用程序中僅有一個(gè)實(shí)例，并提供一個(gè)全局訪問(wèn)點(diǎn)來(lái)獲取這個(gè)實(shí)例。這有助于控制共享資源的訪問(wèn)，比如數(shù)據(jù)庫(kù)連接池、日志系統(tǒng)等。
優(yōu)點(diǎn)

1. 控制資源訪問(wèn)：限制對(duì)昂貴資源的訪問(wèn)，例如數(shù)據(jù)庫(kù)連接或線程池，以避免資源浪費(fèi)。
2. 全局唯一性：保證系統(tǒng)中某些服務(wù)或資源的唯一性，減少因多個(gè)實(shí)例導(dǎo)致的潛在沖突。
3. 簡(jiǎn)化編程模型：對(duì)于需要全局訪問(wèn)的對(duì)象，開(kāi)發(fā)者無(wú)需關(guān)心實(shí)例化細(xì)節(jié)，直接使用即可。

缺點(diǎn)

1. 違反單一職責(zé)原則：單例類(lèi)除了管理自己的狀態(tài)外，還負(fù)責(zé)控制自己的創(chuàng)建過(guò)程，職責(zé)過(guò)多。
2. 測(cè)試?yán)щy：由于單例的全局狀態(tài)，測(cè)試時(shí)難以模擬不同的環(huán)境或狀態(tài)。
3. 擴(kuò)展性問(wèn)題：在需要多個(gè)實(shí)例或不同配置的場(chǎng)景下，單例模式不夠靈活。
4. 并發(fā)問(wèn)題：在多線程環(huán)境下，如果沒(méi)有正確實(shí)現(xiàn)線程安全，可能導(dǎo)致創(chuàng)建多個(gè)實(shí)例。

代碼示例 (Java)
以下是一個(gè)線程安全的懶漢式單例模式實(shí)現(xiàn)：

public class Singleton {private static volatile Singleton instance;// 私有構(gòu)造方法，防止外部直接創(chuàng)建實(shí)例private Singleton() {}// 獲取單例實(shí)例的公共方法public static Singleton getInstance() {if (instance == null) {synchronized (Singleton.class) {if (instance == null) {instance = new Singleton();}}}return instance;}
}

在這個(gè)例子中，Singleton類(lèi)的構(gòu)造方法是私有的，防止外部直接實(shí)例化。getInstance方法提供了獲取單例實(shí)例的途徑，并使用雙重檢查鎖定（double-checked locking）機(jī)制來(lái)確保線程安全和性能，即只有在實(shí)例為null且需要?jiǎng)?chuàng)建時(shí)才進(jìn)行同步操作。這樣既保證了單例的唯一性，又盡可能減少了同步帶來(lái)的性能開(kāi)銷(xiāo).