第2章包裝外觀（Wrapper Facade）：用於在類中封裝函式的結構型模式

阿新 • • 發佈：2019-02-09

可採取下面的步驟來實現包裝外觀模式：

1. 確定現有函式間的內聚的抽象和關係： 像 Win32、 POSIX或 X Windows這樣被實現為獨立的函式和資料結構的傳統 API提供許多內聚的抽象，比如用於網路程式設計、同步和執行緒，以及 GUI管理的機制。但是，由於在像 C這樣的低階語言中缺乏資料抽象支援，開發者常常並不能馬上明瞭這些現有的函式和資料結構是怎樣互相關聯的。因此，應用包裝外觀的第一步就是確定現有 API中的較低階函式之間的內聚的抽象和關係。換句話說，我們通過將現有的低階 API函式和資料結構聚合進一或多個類中來定義一種“物件模型”。

在我們的日誌例子中，我們從仔細檢查我們原來的日誌伺服器實現開始。該實現使用了許多低階函式，由它們實際提供若干內聚的服務，比如同步和網路通訊。例如， mutex_lock和 mutex_unlock函式與互斥體同步抽象相關聯。同樣地， socket、 bind、 listen和 accept函式扮演了網路程式設計抽象的多種角色。
2. 將內聚的函式組聚合進包裝外觀類和方法中： 該步驟可劃分為以下子步驟：
在此步驟中，我們為每組相關於特定抽象的函式和資料結構定義一或多個包裝外觀類。

A. 建立內聚的類： 我們從為每組相關於特定抽象的函式和資料結構定義一或多個包裝外觀類開始。用於建立內聚的類的若干常用標準包括：

確定在底層函式中什麼是通用的 什麼是可變的 ，並把函式分組進類中，從而將變化隔離在統一的介面後面。

將具有高內聚性 （ cohesion）的函式合併進獨立的類中，同時使類之間不必要的耦合最小化。
一般而言，如果原來的 API含有廣泛的相關函式，就有可能必須建立若干包裝外觀類來適當地對事務進行分理。

B. 將多個獨立函式合併進類方法中：

除了將現有函式分組進類中，在每個包裝類中將多個獨立函式組合進數目更少的方法中常常也是有益的。例如，為確保一組低階函式以適當的順序被呼叫，可能必須要採用此設計。

C. 選擇間接層次： 大多數包裝外觀類簡單地將它們的方法呼叫直接轉發給底層的低階函式。如果包裝外觀方法是內聯的，與直接呼叫低階函式相比，可能並沒有額外的間接層次。為增強可擴充套件性，還可以通過動態分派包裝外觀方法實現來增加另外的間接層次。在這種情況下，包裝外觀類扮演橋接（ Bridge）模式 [8]中的抽象（ Abstraction）角色。

D. 確定在哪裡處理平臺特有的變種： 使平臺特有的應用程式碼最少化是使用包裝外觀模式的重要好處。因而，儘管包裝外觀類方法的實現在不同的 OS平臺上可以不同，它們應該提供統一的、平臺無關的介面。
處理平臺特有變種的一種策略是在包裝外觀類方法實現中使用 #ifdef。在聯合使用 #ifdef和自動配置工具（比如 GNU autoconf）時，可以通過單一的原始碼樹建立統一的、不依賴於平臺的包裝外觀。另一種可選策略是將不同的包裝外觀類實現分解進分離的目錄中（例如，每個平臺有一個目錄），並配置語言處理工具，以在編譯時將適當的包裝外觀類包含進應用中。
選擇特定的策略在很大程度上取決於包裝外觀方法實現變動的頻度。例如，如果它們頻繁變動，為每個平臺正確地更新 #ifdef可能是單調乏味的。同樣地，所有依賴於該檔案的檔案可能都需要重編譯，即使變動僅僅對一個平臺來說是必需的。

　在我們的日誌例子中，我們將為互斥體、 socket和執行緒定義包裝外觀類，以演示每一子步驟是怎樣被實施的。如下所示：

互斥體包裝外觀： 我們首先定義 Thread_Mutex抽象，在統一和可移植的類介面中封裝 Solaris互斥體函式：
classThread_Mutex
{
public:
Thread_Mutex(void)
{
mutex_init (&mutex_, 0, 0);
}
　
?Thread_Mutex(void)
{
mutex_destroy (&mutex_);
}
　
int acquire(void)
{
return mutex_lock (&mutex_);
}
　
int release(void)
{
return mutex_unlock (&mutex_);
}
　
private:
//Solaris-specific Mutex mechanism.
mutex_t mutex_;
　
// = Disallowcopying and assignment.
Thread_Mutex(c*****t Thread_Mutex &);
void operator=(c*****t Thread_Mutex &);
};

　　通過定義 Thread_Mutex類介面，並隨之編寫使用它、而不是低階本地 OS CAPI的應用，我們可以很容易地將我們的包裝外觀移植到其他平臺。例如，下面的 Thread_Mutex實現在 Win32上工作：

classThread_Mutex
{
public:
Thread_Mutex(void)
{
InitializeCriticalSection(&mutex_);
}
　
?Thread_Mutex(void)
{
DeleteCriticalSection(&mutex_);
}
　
int acquire(void)
{
EnterCriticalSection (&mutex_);return 0;
}
　
int release(void)
{
LeaveCriticalSection (&mutex_);return 0;
}
　
private:
//Win32-specific Mutex mechanism.
CRITICAL_SECTIONmutex_;
　
// = Disallowcopying and assignment.
Thread_Mutex(c*****t Thread_Mutex &);
void operator=(c*****t Thread_Mutex &);
};

　　如早先所描述的，我們可以通過在 Thread_Mutex方法實現中使用 #ifdef以及自動配置工具（比如 GUN autoconf）來支援多個 OS平臺，以使用單一原始碼樹提供統一的、平臺無關的互斥體抽象。相反，我們也可以將不同的 Thread_Mutex實現分解進分離的目錄中，並指示我們的語言處理工具在編譯時將適當的版本包含進我們的應用中。
　　除了改善可移植性，我們的 Thread_Mutex包裝外觀還提供比直接程式設計低階 Solaris函式和 mutex_t資料結構更不容易出錯的互斥體介面。例如，我們可以使用 C++ private訪問控制指示符來禁止互斥體的拷貝和賦值；這樣的使用是錯誤的，但卻不會被不那麼強型別化的 C程式設計 API所阻止。

socket 包裝外觀： socket API比 Solaris互斥體 API要大得多，也有表現力得多 [5]。因此，我們必須定義一組相關的包裝外觀類來封裝 socket。我們將從定義下面的處理 UNIX/Win32可移植性差異的 typedef開始：
#if !defined(_WINSOCKAPI_)
typedef intSOCKET;
#defineINVALID_HANDLE_VALUE -1
#endif /*_WINSOCKAPI_ */

接下來，我們將定義 INET_Addr類，封裝 Internet域地址結構：

class INET_Addr
{
public:
INET_Addr(u_short port, long addr)
{
// Set up the address to become aserver.
memset (reinterpret_cast <void*> (&addr_), 0, sizeof addr_);
addr_.sin_family = AF_INET;
addr_.sin_port = ht***** (port);
addr_.sin_addr.s_addr = htonl(addr);
}
　
u_shortget_port (void) c*****t
{
return addr_.sin_port;
}
　
longget_ip_addr (void) c*****t
{
return addr_.sin_addr.s_addr;
}
　
sockaddr *addr(void) c*****t
{
return reinterpret_cast<sockaddr *>(&addr_);
}
　
size_t size(void) c*****t
{
return sizeof (addr_);
}
// ...
　
private:
sockaddr_inaddr_;
};

　　注意 INET_Addr構造器是怎樣通過將 sockaddr_in域清零，並確保埠和 IP地址被轉換為網路位元組序，消除若干常見的 socket程式設計錯誤的。
　　下一個包裝外觀類， SOCK_Stream，對應用可在已連線 socket控制代碼上呼叫的 I/O操作（比如 recv和 send）進行封裝：

classSOCK_Stream
{
public:
// =C*****tructors.
// Defaultc*****tructor.
SOCK_Stream(void)
: handle_ (INVALID_HANDLE_VALUE) {}
　
// Initializefrom an existing HANDLE.
SOCK_Stream(SOCKET h): handle_ (h) {}
　
//Automatically close the handle on destruction.
?SOCK_Stream (void){ close (handle_); }
　
void set_handle(SOCKET h) { handle_ = h; }
SOCKETget_handle (void) c*****t { return handle_; }
　
// = I/Ooperati*****.
int recv (char*buf, size_t len, int flags = 0);
int send (c*****tchar *buf, size_t len, int flags = 0);
// ...
　
private:
// Handle forexchanging socket data.
SOCKET handle_;
};

注意此類是怎樣確保 socket控制代碼在 SOCK_Stream物件出作用域時被自動關閉的。
　　SOCK_Stream物件由連線工廠 SOCK_Acceptor建立，後者封裝被動的 連線建立邏輯 [9]。 SOCK_Acceptor構造器初始化被動模式接受器 socket，以在 sock_addr地址上進行偵聽。同樣地， accept工廠方法通過新接受的連線來初始化 SOCK_Stream，如下所示：

classSOCK_Acceptor
{
public:
SOCK_Acceptor(c*****t INET_Addr &sock_addr)
{
// Create a local endpoint ofcommunication.
handle_ = socket (PF_INET,SOCK_STREAM, 0);
　
// Associate address with endpoint.
bind (handle_, sock_addr.addr (), sock_addr.size());
　
// Make endpoint listen forconnecti*****.
listen (handle_, 5);
};
　
// Accept aconnection and initialize
// the<stream>.
int accept(SOCK_Stream &stream)
{
stream.set_handle (accept (handle_,0, 0));
if (stream.get_handle () ==INVALID_HANDLE_VALUE)
return -1;
else return 0;
}
　
private:
// Sockethandle factory.
SOCKET handle_;
};

注意 SOCK_Acceptor的構造器是怎樣確保低階的 socket、 bind和 listen函式總是以正確的次序被呼叫的。
　　完整的 socket包裝外觀集還包括 SOCK_Connector，封裝主動的 連線建立邏輯 [9]。

執行緒外觀： 在不同的 OS平臺上有許多執行緒 API可用，包括 Solaris執行緒、 POSIX Pthreads和 Win32執行緒。這些 API顯示出微妙的語法和語義差異，例如， Solaris和 POSIX執行緒可以“分離”（ detached）模式被派生，而 Win32執行緒則不行。但是，可以提供 Thread_Manager包裝外觀，在統一的 API中封裝這些差異。如下所示：
classThread_Manager
{
public:
int spawn (void*(*entry_point) (void *),
void *arg,
long flags,
long stack_size = 0,
void *stack_pointer = 0,
thread_t *t_id = 0)
{
thread_t t;
if (t_id == 0)
t_id = &t;
　
return thr_create (stack_size,
stack_pointer,
entry_point,
arg,
flags,
t_id);
}
// ...
};

Thread_Manager還提供聯接（ join）和取消執行緒的方法。

1. 確定錯誤處理機制： 低階的 C函式 API通常使用返回值和整型程式碼（比如 errno）來將錯誤通知給它們的呼叫者。但是，此技術是容易出錯的，因為呼叫者可能會忘記檢查它們的函式呼叫的返回狀態。
更為優雅的報告錯誤的方式是使用異常處理。許多程式語言，比如 C++和 Java，使用異常處理來作為錯誤報告機制。它也被某些作業系統所使用，比如 Win32。
使用異常處理作為包裝外觀類的錯誤處理機制有若干好處：

它是可擴充套件的： 現代程式語言允許通過對現有介面和使用干擾極少的特性來擴充套件異常處理策略和機制。例如， C++和 Java使用繼承來定義異常類的層次。 它使錯誤處理與正常處理得以乾淨地去耦合： 例如，錯誤處理資訊不會顯式地傳遞給操作。而且，應用不會因為沒有檢查函式返回值而偶然地忽略異常。 它可以是型別安全的： 在像 C++和 Java這樣的語言中，異常以一種強型別化的方式被扔出和捕捉，以增強錯誤處理程式碼的組織和正確性。相對於顯式地檢查執行緒專有的錯誤值，編譯器會確保對於每種型別的異常，將執行正確的處理器。
但是，為包裝外觀類使用異常處理也有若干缺點：

它不是通用的： 不是所有語言都提供異常處理。例如，某些 C++編譯器沒有實現異常。同樣地，當 OS提供異常服務時，它們必須被語言擴充套件所支援，從而降低了程式碼的可移植性。 它使多種語言的使用變得複雜化： 因為語言以不同的方式實現異常，或根本不實現異常，如果以不同語言編寫的元件扔出異常，可能很難把它們整合在一起。相反，使用整型值或結構來報告錯誤資訊提供了更為通用的解決方案。 它使資源管理變得複雜化： 如果在 C++或 Java程式碼塊中有多個退出路徑，資源管理可能會變得複雜化 [10]。因而，如果語言或程式設計環境不支援垃圾收集，必須注意確保在有異常扔出時刪除動態分配的物件。 它有著潛在的時間和 / 或空間低效的可能性： 即使沒有異常扔出，異常處理的糟糕實現也會帶來時間和 /或空間的過度開銷 [10]。對於必須具有高效和低記憶體佔用特性的嵌入式系統來說，這樣的開銷可能會特別地成問題。
　　對於封裝核心級裝置驅動程式或低階的本地 OS API（它們必須被移植到許多平臺上）的包裝外觀來說，異常處理的缺點也是特別成問題的。對於這些型別的包裝外觀，更為可移植、高效和執行緒安全的處理錯誤的方式是定義錯誤處理器抽象，顯式地維護關於操作的成功或失敗的資訊。使用執行緒專有儲存（ Thread-Specific Storage）模式 [11]是被廣泛用於這些系統級包裝外觀的解決方案。

1. 定義相關助手類（可選）： 一旦低階函式和資料結構被封裝在內聚的包裝外觀類中，常常有可能建立其他助手類來進一步簡化應用開發。通常要在包裝外觀模式已被應用於將低階函式和與其關聯的資料聚合進類中之後，這些助手類的效用才變得明顯起來。
例如，在我們的日誌例子中，我們可以有效地利用下面的實現 C++ ScopedLocking 習語的 Guard類；該習語確保 Thread_Mutex被適當地釋放，不管程式的控制流是怎樣退出作用域的。

template<class LOCK>
class Guard
{
public:
Guard (LOCK&lock): lock_ (lock)
{
lock_.acquire ();
}
　
?Guard (void)
{
lock_.release ();
}
　
private:
// Hold thelock by reference to avoid
// the use ofthe copy c*****tructor...
LOCK&lock_;
}

Guard類應用了 [12]中描述的 C++習語，藉此，在一定作用域中“構造器獲取資源而析構器釋放它們”。如下所示：

// ...
{
// C*****tructorof <mon> automatically
// acquires the<mutex> lock.
Guard<Thread_Mutex>mon (mutex);
　
// ...operati***** that must be serialized ...
　
// Destructorof <mon> automatically
// releases the<mutex> lock.
}
// ...

　　因為我們使用了像 Thread_Mutex包裝外觀這樣的類，我們可以很容易地替換不同型別的鎖定機制，與此同時仍然複用 Guard的自動鎖定 /解鎖協議。例如，我們可以用 Process_Mutex類來取代 Thread_Mutex類，如下所示：

// Acquire aprocess-wide mutex.
Guard<Process_Mutex>mon (mutex);

　　如果使用 C函式和資料結構、而不是 C++類，獲得這種程度的“可插性”（ pluggability）要困難得多。

2.2.9 例子解答
　　下面的程式碼演示日誌伺服器的 main函式，它已使用 2.2.8描述的互斥體、 socket和執行緒的包裝外觀重寫。

// At filescope.
// Keep trackof number of logging requests.
static intrequest_count;
　
// Managethreads in this process.
staticThread_Manager thr_mgr;
　
// Lock to protectrequest_count.
staticThread_Mutex lock;
　
// Forwarddeclaration.
static void*logging_handler (void *);
　
// Port numberto listen on for requests.
static c*****tint logging_port = 10000;
　
// Main driverfunction for the multi-threaded
// loggingserver. Some error handling has been
// omitted tosave space in the example.
int main (intargc, char *argv[])
{
// Internetaddress of server.
INET_Addr addr(port);
　
// Passive-modeacceptor object.
SOCK_Acceptorserver (addr);
　
SOCK_Streamnew_stream;
　
// Wait for aconnection from a client.
for (;;)
{
// Accept a connection from aclient.
server.accept (new_stream);
　
// Get the underlying handle.
SOCKET h = new_stream.get_handle();
　
// Spawn off athread-per-connection.
thr_mgr.spawn (logging_handler,
reinterpret_cast <void *>(h),
THR_DETACHED);
}
}

logging_handler函式執行在單獨的執行緒控制中，也就是，每個相連客戶有一個執行緒。它在各個連線上接收並處理日誌記錄，如下所示：

// Entry pointthat processes logging records for
// one clientconnection.
void*logging_handler (void *arg)
{
SOCKET h =reinterpret_cast <SOCKET> (arg);
　
// Create a<SOCK_Stream> object from SOCKET <h>.
SOCK_Streamstream (h);
for (;;)
{
UINT_32 len; // Ensure a 32-bitquantity.
char log_record[LOG_RECORD_MAX];
　
// The first <recv_n> readsthe length
// (stored as a 32-bit integer) of
// adjacent logging record. Thiscode
// handles"short-<recv>s".
ssize_t n = stream.recv_n
(reinterpret_cast <char *>(&len),
sizeof len);
　
// Bail out if we’re shutdown or
// errors occur unexpectedly.
if (n <= 0) break;
len = ntohl (len); // Convertbyte-ordering.
if (len > LOG_RECORD_MAX) break;
　
// The second <recv_n> thenreads <len>
// bytes to obtain the actualrecord.
// This code handles"short-<recv>s".
n = stream.recv_n (log_record,len);
　
// Bail out if we’re shutdown or
// errors occur unexpectedly.
if (n <= 0) break;
　
{
// C*****tructor of Guardautomatically
// acquires the lock.
Guard<Thread_Mutex> mon(lock);
　
// Execute following two statementsin a
// critical section to avoid raceconditi*****
// and scrambled output,respectively.
++request_count; // Count # ofrequests
　
if (write (STDOUT, log_record, len)== -1)
break;
　
// Destructor of Guardautomatically
// releases the lock, regardless of
// how we exit this block!
}
}
　
// Destructorof <stream> automatically
// closes down<h>.
return 0;
}

注意上面的程式碼是怎樣解決 2.2.2所示程式碼的各種問題的。例如， SOCK_Stream和 Guard的析構器會分別關閉 socket控制代碼和釋放 Thread_Mutex，而不管程式碼塊是怎樣退出的。同樣地，此程式碼要容易移植和維護得多，因為它沒有使用平臺特有的 API。
2.2.10 已知應用
　　本論文中的例子聚焦於併發網路程式設計。但是，包裝外觀模式已被應用到其他的許多領域，比如 GUI構架和資料庫類庫。下面是包裝外觀模式的一些廣為人知的應用：

Microsoft Foundation Class （ MFC ）： MFC提供一組封裝大多數低階 C Win32 API的包裝外觀，主要集中於提供實現 Microsoft文件 /模板體系結構的 GUI元件。

ACE 構架： 2.2.8描述的互斥體、執行緒和 socket的包裝外觀分別基於 ACE構架中的元件 [7]： ACE_Thread_Mutex、 ACE_Thread_Manager和 ACE_SOCK*類。

Rogue Wave 類庫： Rogue Wave的 Net.h++和 Threads.h++類庫在許多 OS平臺上實現了 socket、執行緒和同步機制的包裝外觀。

ObjectSpace System<Toolkit> ：該工具包也提供了 socket、執行緒和同步機制的包裝外觀。

Java 虛擬機器和 Java 基礎類庫： Java虛擬機器（ JVM）和各種 Java基礎類庫，比如 AWT和 Swing，提供了一組封裝大多數低階的本地 OS系統呼叫和 GUI API的包裝外觀。

2.2.11 效果
　　包裝外觀模式提供以下好處：

更為簡潔和健壯的程式設計介面： 包裝外觀模式在一組更為簡潔的 OO類方法中封裝許多低階函式。這減少了使用低階函式和資料結構開發應用的枯燥性，從而降低了發生程式設計錯誤的潛在可能性。

改善應用可移植性和可維護性： 包裝外觀類的實現可用以使應用開發者與低階函式和資料結構的不可移植的方面遮蔽開來。而且，通過用基於邏輯設計 實體（比如基類、子類，以及它們的關係）的應用配置策略取代基於物理設計 實體（比如檔案和 #ifdef）的策略 [6]，包裝外觀模式改善了軟體結構。一般而言，根據應用的邏輯設計、而不是物理設計來理解和維護它們要更為容易一些。

改善應用的模組性、可複用性和可配置性： 通過使用像繼承和引數化型別這樣的 OO語言特性，包裝外觀模式建立的可複用類元件可以一種整體方式被“插入”其他元件，或從中“拔出”。相反，不求助於粗粒度的 OS工具，比如連結器或檔案系統，替換成組的函式要難得多。

包裝外觀模式有以下缺點：

額外的間接性（ Indirection ）：與直接使用低階的函式和資料結構相比，包裝外觀模式可能帶來額外的間接。但是，支援內聯的語言，比如 C++，可以無需顯著的開銷而實現該模式，因為編譯器可以內聯用於實現包裝外觀的方法呼叫。
2.2.12 參見
　　包裝外觀模式與外觀模式是類似的 [8]。外觀模式的意圖是簡化子系統的介面。包裝外觀模式的意圖則更為具體：它提供簡潔、健壯、可移植和可維護的類介面，封裝低階的函式和資料結構，比如本地 OS互斥體、 socket、執行緒和 GUI C語言 API。一般而言，外觀將複雜的類關係隱藏在更簡單的 API後面，而包裝外觀將複雜的函式和資料結構關係隱藏在更豐富的類 API後面。
　　如果動態分派被用於實現包裝外觀方法，包裝外觀模式可使用橋接模式 [8]來實現；包裝外觀方法在橋接模式中扮演抽象（ Abstraction）角色。

2.3 結束語
　　本論文描述包裝外觀模式，並給出了詳細的例子演示怎樣使用它。在本論文中描述的 ACE包裝外觀元件的實現可在 ACE[7]軟體釋出中自由獲取（ URL： http://www.cs.wustl.edu/~schmidt/ACE.html ）。該釋出含有在聖路易斯華盛頓大學開發的完整的 C++原始碼、文件和測試例子驅動程式。目前 ACE正在用於許多公司（像 Bellcore、波音、 DEC、愛立信、柯達、朗訊、摩托羅拉、 SAIC和西門子）的通訊軟體專案中。
感謝
　　感謝 Hans Rohnert、 Regine Meunier、 Michael Stal、 Christa Schwanninger、 Frank Buschmann和 Brad Appleton，他們的大量意見極大地改善了包裝外觀模式描述的形式和內容。

參考文獻
[1] F.Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-OrientedSoftware Architecture - A System of Pattern s. Wiley and S*****, 1996.
[2]W.R.Stevens,UNIX Network Programming, First Editio n. Englewood Cliffs,NJ: Prentice Hall, 1990.
[3] J.Eykholt, S. Kleiman, S. Barton, R. Faulkner, A. Shivalin-giah, M. Smith, D.Stein, J. Voll, M. Weeks, and D. Williams, “Beyond Multiprocessing...Multithreading the SunOS Ker-nel,” in Proceedings of the Summer USENIXConferenc e,(San Antonio, Texas), June 1992.
[4]W.R.Stevens,UNIX Network Programming, Second Editio n. Englewood Cliffs,NJ: Prentice Hall, 1997.
[5] D. C.Schmidt, “IPC SAP: An Object-Oriented Interface to Interprocess Communicati*****ervices,” C++ Repor t,vol.4, November/December 1992.
[6] J.Lakos, Large-scale Software Development with C+ +. Reading, MA:Addison-Wesley, 1995.
[7] D. C.Schmidt, “ACE: an Object-Oriented Framework for Developing DistributedApplicati*****,” in Proceedings of the 6^th USENIX C++ TechnicalConferenc e, (Cambridge, Mas-sachusetts), USENIX Association, April 1994.
[8] E.Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Pat-terns: Elements ofReusable Object-Oriented Softwar e. Read-ing, MA: Addison-Wesley, 1995.
[9] D. C.Schmidt, “Acceptor and Connector: Design Patterns for InitializingCommunication Services,” in Pattern Languages of Program Design (R.Martin, F. Buschmann, and D. Riehle, eds.), Reading, MA: Addison-Wesley, 1997.
[10] H.Mueller, “Patterns for Handling Exception Handling Suc-cessfully,” C++ Repor t,vol. 8, Jan. 1996.
[11] D. C.Schmidt, T. Harrison, and N. Pryce, “Thread-Specific Storage – An ObjectBehavioral Pattern for Accessing per-Thread State Efficiently,” C++ Repor t,vol.9,Novem-ber/December1997.
[12]Bjarne Stroustrup, The C++ Programming Language, 3^rd Editio n.Addison-Wesley, 1998.

This file is decompiled by an unregistered version of ChmDecompiler.
Regsitered version does not show this message.
You can download ChmDecompiler at : [url]http://www.zipghost.com/ [/url]

第2章包裝外觀（Wrapper Facade）：用於在類中封裝函式的結構型模式

第2章包裝外觀（Wrapper Facade）：用於在類中封裝函式的結構型模式

第三部分進階篇-第2章 CC2530 BasicRF（無線點燈）

設計模式C++實現：包裝器外觀模式（Wrapper Facade）

《演算法導論》第三章-第2節_練習（參考答案）

2017.12.8 軟件工程-----第五章總體設計（復習）

hiho 第2周 Trie樹（字典樹）

概論論與數理統計嚴繼高版第六章習題答案（含過程）

概率論與數理統計嚴繼高版第七章習題答案（含過程）

JavaSE習題第八章執行緒（未完成）

【練習題】第四章--互動設計（Think Python）

【練習題】第七章--迭代（Think Python）

【練習題】第五章--條件迴圈（Think Python）

《機器學習》周志華學習筆記第四章決策樹（課後習題）python 實現

《機器學習》周志華學習筆記第三章線性模型（課後習題）python 實現

《機器學習》周志華學習筆記第八章整合學習（課後習題）python實現

《機器學習》周志華學習筆記第五章神經網路（課後習題） python實現

周志華西瓜書第16章強化學習（習題答案）（轉）

Essential c++ 第七章異常處理（exception handling）課後練習

讀書筆記 ---- 《計算機網路—謝希仁第7版》---- 第4章網路層（上篇）

《Java多執行緒程式設計實戰》—— 第8章 Active Object（主動物件）模式

第2章 包裝外觀（Wrapper Facade）：用於在類中封裝函式的結構型模式

相關推薦

第2章包裝外觀（Wrapper Facade）：用於在類中封裝函式的結構型模式