面試中c++ 常用設(shè)模式
單例模式(Singleton Pattern)
工廠模式(Factory Pattern)
策略模式(Strategy Pattern)
觀察者模式(Observer Pattern)
訪問者模式(Visitor Pattern)
建造者模式(Builder Pattern)
適配器模式(Adapter Pattern)
橋接模式(Bridge Pattern)
裝飾器模式(Decorator Pattern)
組合模式(Composite Pattern)
迭代器模式(Iterator Pattern)
外觀模式(Facade Pattern)
職責(zé)鏈模式(Chain of Responsibility Pattern)
命令模式(Command Pattern)
解釋器模式(Interpreter Pattern)
中介者模式(Mediator Pattern)
1.單例模式(Singleton Pattern)
單例模式是一種創(chuàng)建型設(shè)計(jì)模式，它保證一個(gè)類只有一個(gè)實(shí)例，并提供全局訪問點(diǎn)。
單例模式的主要思想是通過私有化類的構(gòu)造器，使得外部無法直接創(chuàng)建該類的實(shí)例。然后在類內(nèi)部維護(hù)一個(gè)唯一的實(shí)例，并提供一個(gè)靜態(tài)方法用于獲取該實(shí)例。這樣，在整個(gè)應(yīng)用程序中，只有一個(gè)實(shí)例存在，所有需要使用該實(shí)例的地方都可以通過該靜態(tài)方法獲取到該實(shí)例。
單例模式主要有兩種實(shí)現(xiàn)方式：懶漢式和餓漢式。懶漢式單例模式在第一次調(diào)用靜態(tài)方法時(shí)才創(chuàng)建實(shí)例，而餓漢式單例模式則在類加載時(shí)就創(chuàng)建了實(shí)例。
單例模式的優(yōu)點(diǎn)包括：
提供唯一實(shí)例，減少內(nèi)存消耗。
簡(jiǎn)化了代碼，避免了多個(gè)實(shí)例之間的沖突。
可以控制全局資源的并發(fā)訪問。
單例模式的缺點(diǎn)包括：
因?yàn)閱卫Ｊ娇刂屏藢?shí)例的數(shù)量，所以可能會(huì)導(dǎo)致系統(tǒng)擴(kuò)展困難。
單例模式增加了程序的復(fù)雜度，降低了代碼的靈活性。
單例模式在多線程環(huán)境下使用時(shí)需要考慮線程安全問題。
2.工廠模式(Factory Pattern)
工廠模式是一種創(chuàng)建型設(shè)計(jì)模式，它提供了一種創(chuàng)建對(duì)象的最佳方式。工廠模式通過使用工廠方法來處理創(chuàng)建對(duì)象的過程，并將這個(gè)過程推遲到子類中，從而使得主要的代碼邏輯與實(shí)例化解耦。這意味著在程序運(yùn)行時(shí)，可以改變對(duì)象的類型而不影響主要的代碼邏輯。
在工廠模式中，我們定義一個(gè)工廠接口以及該接口的實(shí)現(xiàn)類。這個(gè)工廠接口和實(shí)現(xiàn)類負(fù)責(zé)創(chuàng)建某些類的實(shí)例。然后我們使用這個(gè)工廠來創(chuàng)建對(duì)象并且隱藏創(chuàng)建的過程。這樣做的好處是如果我們需要改變對(duì)象的類型，我們只需要改變工廠的實(shí)現(xiàn)，而無需修改調(diào)用者的代碼。
總之，工廠模式使得代碼更加靈活、可擴(kuò)展、易于維護(hù)，并且可以減少代碼重復(fù)。常見的工廠模式有簡(jiǎn)單工廠模式、工廠方法模式和抽象工廠模式。
3.策略模式(Strategy Pattern)
策略模式是一種行為型設(shè)計(jì)模式，它允許在運(yùn)行時(shí)動(dòng)態(tài)地改變對(duì)象的行為。策略模式將算法與其實(shí)現(xiàn)分離，使得算法可以獨(dú)立于其使用者而變化。
在策略模式中，我們定義了一個(gè)抽象的策略接口，以及一些具體的策略類來實(shí)現(xiàn)這個(gè)接口。然后我們創(chuàng)建一個(gè)上下文類，該類包含一個(gè)指向策略接口的引用。在運(yùn)行時(shí)，我們可以動(dòng)態(tài)地改變上下文類中的策略引用，從而改變其行為。
策略模式的好處是可以將不同的算法封裝到不同的策略類中，從而避免了代碼的重復(fù)。另外，由于策略類是相互獨(dú)立的，所以我們可以通過增加新的策略類來擴(kuò)展系統(tǒng)的功能。
常見的應(yīng)用場(chǎng)景包括排序算法、搜索算法、壓縮算法等等。例如，在一個(gè)排序系統(tǒng)中，我們可以定義一個(gè)排序接口和多個(gè)具體的排序策略類來實(shí)現(xiàn)不同的排序算法，然后在運(yùn)行時(shí)根據(jù)需要選擇合適的排序策略來對(duì)數(shù)據(jù)進(jìn)行排序。
總之，策略模式使得程序更加靈活、可擴(kuò)展，并且提高了代碼的可維護(hù)性。
4.觀察者模式(Observer Pattern)
觀察者模式是一種設(shè)計(jì)模式，用于在對(duì)象之間定義一對(duì)多的依賴關(guān)系，使得當(dāng)一個(gè)對(duì)象改變狀態(tài)時(shí)，它的所有依賴者都能收到通知并自動(dòng)更新。
該模式包含兩個(gè)主要角色：Subject（被觀察者）和Observer（觀察者）。Subject維護(hù)著一組觀察者，并提供了添加和刪除觀察者的接口。當(dāng)Subject的狀態(tài)發(fā)生改變時(shí)，它會(huì)通知所有觀察者，并在通知中傳遞狀態(tài)信息。Observer則實(shí)現(xiàn)了一個(gè)更新接口，以便能夠接收Subject的通知并進(jìn)行相應(yīng)的處理。
觀察者模式有以下優(yōu)點(diǎn)：
1.松耦合：Subject和Observer之間是松耦合的，它們之間的關(guān)系通過抽象接口建立，從而使它們可以獨(dú)立地改變和擴(kuò)展。
2.可重用性：Subject和Observer可以被多次重用，因?yàn)樗鼈冎g的關(guān)系是抽象的。
3.靈活性：Subject和Observer之間可以動(dòng)態(tài)地建立和解除關(guān)系，因此它們之間的交互可以在運(yùn)行時(shí)動(dòng)態(tài)地改變。
4.增強(qiáng)了對(duì)象的一致性：Subject和Observer之間的關(guān)系使得它們共同構(gòu)成了一個(gè)整體，即使系統(tǒng)中的其他部分發(fā)生改變，它們之間的關(guān)系也不會(huì)受到影響。
觀察者模式在很多地方都有應(yīng)用，比如GUI編程、事件處理等。例如，在GUI編程中，當(dāng)用戶點(diǎn)擊某個(gè)按鈕時(shí)，該按鈕可以充當(dāng)Subject，而該按鈕上的所有組件（包括標(biāo)簽、文本框等）可以充當(dāng)Observer，這些組件將根據(jù)按鈕的狀態(tài)自動(dòng)更新自己的內(nèi)容。
5.訪問者模式(Visitor Pattern)
訪問者模式是一種行為型設(shè)計(jì)模式，它允許你定義一些操作，這些操作可以應(yīng)用于不同的對(duì)象結(jié)構(gòu)中的元素。通過這種方式，你可以在不改變各個(gè)元素類別或這些類別之間的關(guān)系的情況下，向現(xiàn)有對(duì)象結(jié)構(gòu)添加新的操作。
簡(jiǎn)單來說，訪問者模式就是將某些操作（訪問者）與數(shù)據(jù)結(jié)構(gòu)（被訪問者）分離開來，從而使得操作和數(shù)據(jù)結(jié)構(gòu)能夠獨(dú)立地變化，擴(kuò)展性更好。
在訪問者模式中，數(shù)據(jù)結(jié)構(gòu)中的每個(gè)元素都擁有一個(gè) accept 方法，該方法會(huì)接受訪問者作為參數(shù)，并調(diào)用訪問者的 visit 方法來執(zhí)行具體的操作。訪問者則需要實(shí)現(xiàn)與不同元素類型相對(duì)應(yīng)的多個(gè) visit 方法，以便在訪問時(shí)執(zhí)行正確的操作。
使用訪問者模式可以有效地減少代碼重復(fù)，并且支持在運(yùn)行時(shí)動(dòng)態(tài)地添加新的操作。但同時(shí)也會(huì)增加代碼的復(fù)雜度，因此需要慎重選擇是否使用該模式。
6.建造者模式(Builder Pattern)
建造者模式是一種創(chuàng)建型設(shè)計(jì)模式，它允許你在不同的對(duì)象上使用相同的構(gòu)建代碼來創(chuàng)建不同的表示形式。該模式將對(duì)象的構(gòu)建過程分離出來，并且使得可以通過單獨(dú)的方式創(chuàng)建和組合復(fù)雜的對(duì)象。
簡(jiǎn)單來說，建造者模式就是將一個(gè)復(fù)雜對(duì)象的構(gòu)建過程與其表示分離開來，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
在建造者模式中，通常會(huì)定義一個(gè) Builder 接口，這個(gè)接口包括所有必須實(shí)現(xiàn)的方法，用于指定要構(gòu)建的每個(gè)部分。然后有一個(gè)具體的 Builder 類，它實(shí)現(xiàn)了 Builder 接口并包含了具體的構(gòu)建邏輯。最終，有一個(gè) Director 類，它負(fù)責(zé)使用 Builder 對(duì)象來構(gòu)建最終的對(duì)象，并且根據(jù)需要可以通過改變 Builder 對(duì)象來修改構(gòu)建結(jié)果。
使用建造者模式可以有效地解耦構(gòu)建過程和最終表示，增加代碼的可讀性和可維護(hù)性。但同時(shí)也會(huì)增加工作量和代碼量，因此需要慎重選擇是否使用該模式。
7.適配器模式(Adapter Pattern)
適配器模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，它允許你將不兼容的對(duì)象包裝在適配器中，以便它們能夠協(xié)同工作。該模式將目標(biāo)類和不兼容的類進(jìn)行適配，使得目標(biāo)類能夠使用不兼容的類的功能。
簡(jiǎn)單來說，適配器模式就是通過一個(gè)適配器來轉(zhuǎn)換一種接口到另一種接口，使得原本不兼容的類可以協(xié)同工作。
在適配器模式中，通常會(huì)有一個(gè)目標(biāo)接口和一個(gè)適配器類。目標(biāo)接口定義了客戶端使用的接口，而適配器類則實(shí)現(xiàn)了目標(biāo)接口，并且包含了一個(gè)不兼容的類的實(shí)例。適配器類需要將客戶端調(diào)用的方法轉(zhuǎn)換為不兼容類的方法調(diào)用，以實(shí)現(xiàn)目標(biāo)接口。
使用適配器模式可以有效地解決不兼容的問題，并且可以減少代碼修改的影響范圍。但同時(shí)也會(huì)增加代碼的復(fù)雜度，因此需要慎重選擇是否使用該模式。
8.橋接模式(Bridge Pattern)
橋接模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，它的主要目的是將一個(gè)大類或復(fù)雜的類分解成兩個(gè)或多個(gè)簡(jiǎn)單的類，這些簡(jiǎn)單的類可以獨(dú)立地進(jìn)行修改和維護(hù)。橋接模式通過組合關(guān)系（而不是繼承關(guān)系）連接這些簡(jiǎn)單的類，從而實(shí)現(xiàn)了大類或復(fù)雜類的功能。
橋接模式中的核心概念是“橋”，它允許客戶端代碼使用抽象接口而不必關(guān)心具體實(shí)現(xiàn)。在橋接模式中，抽象部分和實(shí)現(xiàn)部分可以分別獨(dú)立地?cái)U(kuò)展，從而使得系統(tǒng)更加靈活和可擴(kuò)展。
橋接模式適用于以下幾種情況：
當(dāng)一個(gè)類具有多個(gè)變化因素時(shí)，可以使用橋接模式將這些變化因素分離出來，從而使得系統(tǒng)更加靈活和可擴(kuò)展。
當(dāng)需要在多個(gè)平臺(tái)之間共享代碼時(shí)，可以使用橋接模式來保持各個(gè)平臺(tái)的獨(dú)立性。
當(dāng)需要支持多種數(shù)據(jù)源時(shí)，可以使用橋接模式來將數(shù)據(jù)源和數(shù)據(jù)處理邏輯分離開來。
橋接模式的優(yōu)點(diǎn)包括：
橋接模式可以減少類的數(shù)量，降低系統(tǒng)的復(fù)雜度。
橋接模式可以提高系統(tǒng)的靈活性和可擴(kuò)展性，因?yàn)槌橄蟛糠趾蛯?shí)現(xiàn)部分可以獨(dú)立地進(jìn)行修改和擴(kuò)展。
橋接模式可以使得系統(tǒng)更加穩(wěn)定和可靠，因?yàn)槌橄蟛糠趾蛯?shí)現(xiàn)部分是分離的，一個(gè)部分的變化不會(huì)影響到另一個(gè)部分。
橋接模式的缺點(diǎn)包括：
橋接模式需要額外的編碼工作，因?yàn)樾枰x抽象部分和實(shí)現(xiàn)部分之間的橋接接口。
橋接模式增加了系統(tǒng)的復(fù)雜度，因?yàn)樾枰獙?duì)系統(tǒng)進(jìn)行分層設(shè)計(jì)。
9.裝飾器模式(Decorator Pattern)
裝飾器模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，它允許在不修改現(xiàn)有對(duì)象的情況下，動(dòng)態(tài)地將行為添加到對(duì)象中。裝飾器模式的核心思想是通過包裝（即裝飾）一個(gè)對(duì)象來擴(kuò)展其功能。
在裝飾器模式中，有一個(gè)基礎(chǔ)組件（Component）和多個(gè)裝飾器（Decorator）?；A(chǔ)組件是被裝飾的對(duì)象，而裝飾器則用于包裝這個(gè)對(duì)象，并添加額外的行為。每個(gè)裝飾器都實(shí)現(xiàn)了與基礎(chǔ)組件相同的接口，從而可以像基礎(chǔ)組件一樣被使用。
舉個(gè)例子，假設(shè)你正在開發(fā)一個(gè)咖啡店應(yīng)用程序，其中有一個(gè)基礎(chǔ)咖啡（Coffee）類?，F(xiàn)在，你需要添加一些調(diào)料，比如牛奶、糖等。你可以使用裝飾器模式來實(shí)現(xiàn)：創(chuàng)建一個(gè)調(diào)料裝飾器（CondimentDecorator）類作為基礎(chǔ)裝飾器，然后創(chuàng)建具體的調(diào)料裝飾器類（MilkDecorator、SugarDecorator等），并將它們包裝在基礎(chǔ)咖啡（Coffee）對(duì)象上。
優(yōu)點(diǎn)：
裝飾器模式避免了在代碼中添加大量子類的情況，提高了代碼靈活性和可維護(hù)性。
裝飾器模式可以動(dòng)態(tài)地添加或刪除對(duì)象的行為，而不會(huì)影響其他對(duì)象。
裝飾器模式遵循開放封閉原則（OCP），可以在不修改現(xiàn)有代碼的情況下擴(kuò)展對(duì)象的功能。
缺點(diǎn)：
使用裝飾器模式可能會(huì)導(dǎo)致過多的小類，這可能會(huì)使代碼變得更加復(fù)雜。
裝飾器模式增加了代碼的復(fù)雜性和理解難度。
適用場(chǎng)景：
當(dāng)需要?jiǎng)討B(tài)地添加或刪除對(duì)象的行為時(shí)，可以使用裝飾器模式。
當(dāng)需要擴(kuò)展一個(gè)類的功能，但是不希望修改其代碼時(shí)，可以使用裝飾器模式。
當(dāng)需要在運(yùn)行時(shí)動(dòng)態(tài)地給對(duì)象添加功能，并且通過繼承來擴(kuò)展對(duì)象功能并不切實(shí)際時(shí)，可以使用裝飾器模式。
10.組合模式(Composite Pattern)
組合模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，它允許將對(duì)象組合成樹形結(jié)構(gòu)以表示"部分-整體"關(guān)系，使客戶端能夠以統(tǒng)一的方式處理單個(gè)對(duì)象和組合對(duì)象。
在組合模式中，有兩種類型的對(duì)象：葉子節(jié)點(diǎn)和組合節(jié)點(diǎn)。葉子節(jié)點(diǎn)表示樹形結(jié)構(gòu)中最基本的元素，它們沒有子節(jié)點(diǎn)；而組合節(jié)點(diǎn)表示由多個(gè)子節(jié)點(diǎn)組成的復(fù)雜對(duì)象，它們可以包含任意數(shù)量和類型的子節(jié)點(diǎn)。這樣就可以通過遞歸遍歷整個(gè)樹形結(jié)構(gòu)來處理每個(gè)節(jié)點(diǎn)。
組合模式的優(yōu)點(diǎn)在于它簡(jiǎn)化了客戶端的代碼，并且增加新的節(jié)點(diǎn)類型也非常容易。缺點(diǎn)在于可能會(huì)導(dǎo)致過度設(shè)計(jì)，因?yàn)樗鼘蝹€(gè)對(duì)象和組合對(duì)象視為等價(jià)的。此外，組合模式還需要考慮處理葉子節(jié)點(diǎn)的情況，以確保遞歸不會(huì)陷入死循環(huán)。
11.迭代器模式(Iterator Pattern)
迭代器模式是一種行為型設(shè)計(jì)模式，它提供了一種訪問集合對(duì)象中各個(gè)元素的方法，而不需要暴露該對(duì)象的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。
迭代器模式有兩個(gè)核心角色：迭代器和可迭代對(duì)象。迭代器是一個(gè)用于遍歷集合對(duì)象的接口，定義了訪問集合中各個(gè)元素的方法；而可迭代對(duì)象是一個(gè)包含多個(gè)元素的集合對(duì)象，通常實(shí)現(xiàn)了一個(gè)返回迭代器的方法，使得客戶端可以通過迭代器逐個(gè)訪問集合中的元素。
迭代器模式的主要優(yōu)點(diǎn)在于它將集合對(duì)象和遍歷算法分離開來，使得它們可以獨(dú)立變化。這樣就可以方便地添加新的遍歷方式或者更換底層集合結(jié)構(gòu)，同時(shí)也保證了代碼的可讀性和可維護(hù)性。缺點(diǎn)在于迭代器模式會(huì)增加代碼的復(fù)雜性，因?yàn)樾枰~外的類和接口來實(shí)現(xiàn)遍歷功能，同時(shí)也可能會(huì)犧牲一些執(zhí)行效率。
迭代器模式在實(shí)際應(yīng)用中非常廣泛，例如在Java的集合框架中就使用了Iterator接口來實(shí)現(xiàn)集合的遍歷。
12.外觀模式(Facade Pattern)
外觀模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，它提供了一個(gè)簡(jiǎn)化的接口，用于訪問復(fù)雜系統(tǒng)中的一組接口。這個(gè)簡(jiǎn)化的接口就像是一個(gè)"外觀"，隱藏了系統(tǒng)的復(fù)雜性，并向客戶端提供了一組更簡(jiǎn)單、更易用的操作。
外觀模式有一個(gè)核心角色：外觀類。外觀類是一個(gè)具有簡(jiǎn)化接口功能的高層接口，它封裝了系統(tǒng)的復(fù)雜性，向客戶端提供了一個(gè)更為簡(jiǎn)單和易用的接口。通常情況下，外觀類會(huì)調(diào)用一組低層次的子系統(tǒng)接口來完成它所需要的功能。客戶端只需要與外觀類進(jìn)行交互，而不需要知道系統(tǒng)內(nèi)部的復(fù)雜細(xì)節(jié)。
外觀模式的主要優(yōu)點(diǎn)在于它可以幫助客戶端減少與復(fù)雜系統(tǒng)的耦合度，從而提高代碼的可讀性和可維護(hù)性。同時(shí)它還能夠簡(jiǎn)化客戶端的代碼，使得客戶端能夠更加容易地使用系統(tǒng)。缺點(diǎn)在于它可能會(huì)造成系統(tǒng)的性能損失，因?yàn)橥庥^類通常需要調(diào)用一組低層次的子系統(tǒng)接口來完成它所需要的功能。
外觀模式在實(shí)際應(yīng)用中非常廣泛，例如在Java中的Servlet API中就使用了外觀模式，將所有與Servlet請(qǐng)求相關(guān)的操作都封裝在javax.servlet.http.HttpServletRequest和javax.servlet.http.HttpServletResponse中。這樣就能夠簡(jiǎn)化客戶端代碼，并減少對(duì)底層實(shí)現(xiàn)細(xì)節(jié)的依賴。
13.職責(zé)鏈模式(Chain of Responsibility Pattern)
職責(zé)鏈模式是一種行為型設(shè)計(jì)模式，它允許多個(gè)處理器對(duì)象逐個(gè)處理某個(gè)請(qǐng)求，直到其中一個(gè)處理器能夠處理該請(qǐng)求為止。職責(zé)鏈模式的核心思想是將請(qǐng)求和處理器解耦，從而使得請(qǐng)求可以沿著處理器鏈依次傳遞，直到找到一個(gè)可以處理該請(qǐng)求的處理器為止。
職責(zé)鏈模式有三個(gè)核心角色：抽象處理器、具體處理器和客戶端。抽象處理器定義了一個(gè)接口，用于處理請(qǐng)求和設(shè)置下一個(gè)處理器；具體處理器實(shí)現(xiàn)了抽象處理器接口，并負(fù)責(zé)處理特定類型的請(qǐng)求；客戶端創(chuàng)建處理器鏈，并向鏈的開頭發(fā)送請(qǐng)求。當(dāng)請(qǐng)求到達(dá)鏈的某個(gè)處理器時(shí)，該處理器會(huì)嘗試處理請(qǐng)求，如果無法處理該請(qǐng)求，則將請(qǐng)求傳遞給下一個(gè)處理器。
職責(zé)鏈模式的主要優(yōu)點(diǎn)在于它能夠動(dòng)態(tài)地調(diào)整和擴(kuò)展處理器鏈，同時(shí)還能夠避免請(qǐng)求發(fā)送者和接收者之間的顯式耦合關(guān)系。缺點(diǎn)在于它可能會(huì)導(dǎo)致請(qǐng)求被多次處理或者完全無法處理，因此需要謹(jǐn)慎設(shè)計(jì)處理器鏈，以確保每個(gè)請(qǐng)求都能夠得到正確的處理。
職責(zé)鏈模式在實(shí)際應(yīng)用中非常廣泛，例如Java中的Servlet Filter就是一種職責(zé)鏈模式的實(shí)現(xiàn)，用于在Web應(yīng)用中處理HTTP請(qǐng)求和響應(yīng)。
14.命令模式(Command Pattern)
命令模式是一種行為型設(shè)計(jì)模式，它將請(qǐng)求封裝成一個(gè)對(duì)象，并將操作的執(zhí)行者和接收者分離開來。命令模式允許請(qǐng)求發(fā)送者與接收者松散耦合，從而使得系統(tǒng)更加靈活。
在命令模式中，有四個(gè)核心角色：命令、具體命令、調(diào)用者和接收者。命令是一個(gè)抽象類或接口，定義了執(zhí)行操作的方法；具體命令實(shí)現(xiàn)了命令接口，并封裝了一個(gè)接收者和一個(gè)操作；調(diào)用者負(fù)責(zé)創(chuàng)建和存儲(chǔ)命令對(duì)象，并向命令對(duì)象發(fā)送執(zhí)行請(qǐng)求；接收者負(fù)責(zé)執(zhí)行實(shí)際的操作。
命令模式的主要優(yōu)點(diǎn)在于它能夠?qū)⒄?qǐng)求者和接收者解耦，使得系統(tǒng)更加靈活。例如，在GUI應(yīng)用程序中，可以使用命令模式來實(shí)現(xiàn)一組撤銷/重做功能，從而允許用戶撤銷最近的操作。缺點(diǎn)在于命令對(duì)象可能會(huì)導(dǎo)致系統(tǒng)復(fù)雜化，因?yàn)樾枰獎(jiǎng)?chuàng)建多個(gè)命令對(duì)象，并將它們連接在一起。
命令模式在實(shí)際應(yīng)用中也有很多的使用場(chǎng)景，例如Java中的AWT事件處理機(jī)制就使用了命令模式，每個(gè)AWT組件都有一個(gè)addActionListener()方法，用于為該組件添加一個(gè)ActionListener對(duì)象，當(dāng)用戶觸發(fā)該組件時(shí)，會(huì)調(diào)用ActionListener對(duì)象的actionPerformed()方法。
15.解釋器模式(Interpreter Pattern)
解釋器模式是一種行為型設(shè)計(jì)模式，它可以用來解釋一些特定的語法規(guī)則。這種模式通常用于處理自然語言或數(shù)學(xué)表達(dá)式等問題。
在解釋器模式中，有兩個(gè)核心角色：抽象表達(dá)式和具體表達(dá)式。抽象表達(dá)式定義了一個(gè)解釋器的接口，包含了一個(gè)interpret()方法；具體表達(dá)式實(shí)現(xiàn)了抽象表達(dá)式接口，并負(fù)責(zé)解析和執(zhí)行特定的語法規(guī)則。
解釋器模式的主要優(yōu)點(diǎn)在于它能夠簡(jiǎn)化語法規(guī)則的解析和執(zhí)行，并提供了靈活性和可擴(kuò)展性。缺點(diǎn)在于它可能會(huì)導(dǎo)致代碼變得復(fù)雜，因?yàn)樾枰獎(jiǎng)?chuàng)建多個(gè)類來表示不同的語法規(guī)則，并且每個(gè)具體表達(dá)式都需要實(shí)現(xiàn)interpret()方法。
解釋器模式在實(shí)際應(yīng)用中也有一些使用場(chǎng)景，例如在編譯器、數(shù)據(jù)庫查詢、正則表達(dá)式等領(lǐng)域中都有應(yīng)用。例如，在編譯器中，解釋器模式可以用來將源代碼轉(zhuǎn)換成中間代碼或機(jī)器代碼。
16.中介者模式(Mediator Pattern)
中介者模式是一種行為型設(shè)計(jì)模式，它允許對(duì)象之間進(jìn)行通信，而不需要直接相互引用。中介者模式通過封裝對(duì)象之間的交互，從而使得這些對(duì)象可以松散耦合，并且可以獨(dú)立地改變它們之間的交互方式。
在中介者模式中，有三個(gè)核心角色：中介者、抽象同事類和具體同事類。中介者定義了一個(gè)接口，用于與各個(gè)同事對(duì)象通信；抽象同事類定義了一個(gè)接口，用于向中介者發(fā)送消息；具體同事類實(shí)現(xiàn)了抽象同事類接口，并負(fù)責(zé)處理特定類型的消息。
中介者模式的主要優(yōu)點(diǎn)在于它能夠降低系統(tǒng)的復(fù)雜度，因?yàn)樗鼘?duì)象之間的交互抽象成一個(gè)中介者對(duì)象，從而減少了對(duì)象之間的直接依賴關(guān)系。同時(shí)它還可以方便地?cái)U(kuò)展系統(tǒng)，因?yàn)榭梢酝ㄟ^增加或修改中介者來改變對(duì)象之間的交互方式。缺點(diǎn)在于它可能會(huì)導(dǎo)致中介者對(duì)象變得過于復(fù)雜，因?yàn)樾枰幚砀鞣N不同的消息類型。
中介者模式在實(shí)際應(yīng)用中也有很多的使用場(chǎng)景，例如在GUI程序中，可以使用中介者模式來管理不同組件之間的交互，從而使得程序更加易于維護(hù)和擴(kuò)展。
