（1）的選擇是開(kāi)發(fā)一個(gè)軟件系統(tǒng)時(shí)的基本設(shè)計(jì)決策；（2）是最底層的模式，關(guān)注軟件系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，描述了如何實(shí)現(xiàn)構(gòu)件及構(gòu)件之間的關(guān)系。引用計(jì)數(shù)是C++管理動(dòng)態(tài)資源時(shí)常用的一種（3）。

（1）的選擇是開(kāi)發(fā)一個(gè)軟件系統(tǒng)時(shí)的基本設(shè)計(jì)決策；（2）是最底層的模式，關(guān)注軟件系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，描述了如何實(shí)現(xiàn)構(gòu)件及構(gòu)件之間的關(guān)系。引用計(jì)數(shù)是C++管理動(dòng)態(tài)資源時(shí)常用的一種（3）。

Windows操作系統(tǒng)在圖形用戶(hù)界面處理方面采用的核心架構(gòu)風(fēng)格是（1）風(fēng)格。Java語(yǔ)言宣傳的"一次編寫(xiě)，到處運(yùn)行"的特性，從架構(gòu)風(fēng)格上看符合（2）風(fēng)格的特點(diǎn)。

某軟件公司欲開(kāi)發(fā)一個(gè)Windows平臺(tái)上的公告板系統(tǒng)。在明確用戶(hù)需求后，該公司的架構(gòu)師決定采用Command模式實(shí)現(xiàn)該系統(tǒng)的界面顯示部分，并設(shè)計(jì)UML類(lèi)圖，如圖8-41所示。圖中與Command模式中的"Invoker"角色相對(duì)應(yīng)的類(lèi)是（1），與"ConcreteCommand"角色相對(duì)應(yīng)的類(lèi)是（2）。

某軟件公司欲開(kāi)發(fā)一個(gè)Windows平臺(tái)上的公告板系統(tǒng)。在明確用戶(hù)需求后，該公司的架構(gòu)師決定采用Command模式實(shí)現(xiàn)該系統(tǒng)的界面顯示部分，并設(shè)計(jì)UML類(lèi)圖，如圖8-41所示。圖中與Command模式中的"Invoker"角色相對(duì)應(yīng)的類(lèi)是（1），與"ConcreteCommand"角色相對(duì)應(yīng)的類(lèi)是（2）。

當(dāng)不適合采用生成子類(lèi)的方法對(duì)已有的類(lèi)進(jìn)行擴(kuò)充時(shí)，可以采用（1）設(shè)計(jì)模式動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)；當(dāng)應(yīng)用程序由于使用大量的對(duì)象，造成很大的存儲(chǔ)開(kāi)銷(xiāo)時(shí)，可以采用（2）設(shè)計(jì)模式運(yùn)用共享技術(shù)來(lái)有效地支持大量細(xì)粒度的對(duì)象；當(dāng)想使用一個(gè)已經(jīng)存在的類(lèi)，但其接口不符合需求時(shí)，可以采用（3）設(shè)計(jì)模式將該類(lèi)的接口轉(zhuǎn)換成我們希望的接口。

當(dāng)不適合采用生成子類(lèi)的方法對(duì)已有的類(lèi)進(jìn)行擴(kuò)充時(shí)，可以采用（1）設(shè)計(jì)模式動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)；當(dāng)應(yīng)用程序由于使用大量的對(duì)象，造成很大的存儲(chǔ)開(kāi)銷(xiāo)時(shí)，可以采用（2）設(shè)計(jì)模式運(yùn)用共享技術(shù)來(lái)有效地支持大量細(xì)粒度的對(duì)象；當(dāng)想使用一個(gè)已經(jīng)存在的類(lèi)，但其接口不符合需求時(shí)，可以采用（3）設(shè)計(jì)模式將該類(lèi)的接口轉(zhuǎn)換成我們希望的接口。

如圖8-40（a）所示的UML類(lèi)圖描繪的是設(shè)計(jì)模式中的（1）模式。如圖8-40（b）所示的UML類(lèi)圖描述了該模式的一種應(yīng)用，其中與圖8-40（a）中的"Creator"對(duì)應(yīng)的類(lèi)是（2）。