ラッパーライブラリ(またはライブラリラッパー)は、ライブラリの既存のインターフェースを互換性のあるインターフェースに 変換する薄いコード層(「シム」)で構成されています。これはいくつかの理由で行われます。
ラッパー ライブラリは、アダプタ、ファサード、および程度は低いもののプロキシ デザイン パターンを使用して実装できます。
ラッパーライブラリの実装方法は、それが記述されている環境や想定されるシナリオによって大きく異なります。これは、言語間/ランタイム間の相互運用性が考慮される場合に特に当てはまります。
以下は、C POSIXライブラリヘッダー<pthread.h>(POSIXスレッド、または「pthreads」)を介した一般的なラッパーライブラリ実装の一般的な図解です。この例では、C++インターフェースがCインターフェースの「ラッパー」として機能します。
<pthread.h>内:
#include <sys/types.h>
// 以前の宣言...
int pthread_mutex_init ( pthread_mutex_t * mutex , const pthread_mutexattr_t * attr ); int pthread_mutex_destroy ( pthread_mutex_t * mutex ); int pthread_mutex_lock ( pthread_mutex_t * mutex ); int pthread_mutex_unlock ( pthread_mutex_t * mutex ); // その他の関数...
<pthread.h> をPosixThread.cppmでラップする:
モジュールorg.posix.PosixThreadをエクスポートします。
< pthread.h >をインポートします。
エクスポート名前空間org :: posix {
// 以前のラッパー...
クラスThreadMutex { private : :: pthread_mutex_t mutex ;
フレンドクラスThreadLock ;
void lock () noexcept { :: pthread_mutex_lock ( & mutex ); }
void unlock () noexcept { :: pthread_mutex_unlock ( & mutex ); } public : ThreadMutex () { :: pthread_mutex_init ( & mutex , 0 ); }
~ ThreadMutex () { :: pthread_mutex_destroy ( & mutex ); } };
クラスThreadLock { private : ThreadMutex & mutex ; public : explicit ThreadLock ( ThreadMutex & mutex ) : mutex { mutex } { mutex . lock (); }
~ ThreadLock () { mutex . unlock (); } };
// さらにラッパー...
}
オリジナルのCインターフェースは、特にライブラリのユーザーが既にロックされているミューテックスのロックを解除し忘れた場合に、エラーが発生しやすいと考えられていました。新しいインターフェースは、新しいクラスとクラスにおけるリソース取得初期化(RAII)を効果的に活用し、最終的にロックが解除され、オブジェクトが自動的に解放されることを保証します。
org::posix::ThreadMutexorg::posix::ThreadLockorg::posix::ThreadMutexpthread_mutex_t
上記のコードは、Boost.Thread ライブラリの一部である
Boostのクラスboost::scoped_lockの実装を厳密に模倣しています。boost::mutex
クライアントアプリケーションと互換性のない技術を使用して作成されたライブラリとの間の橋渡しとして機能するラッパーライブラリが存在します。例えば、Javaアプリケーションはシステムコールを実行する必要がある場合があります。しかし、システムコールは通常、Cライブラリ関数として公開されています。この問題を解決するために、JavaはこれらのシステムコールをJavaアプリケーションから呼び出せるようにするラッパーライブラリを実装しています。
これを実現するために、Javaなどの言語では、外部関数インターフェースと呼ばれるメカニズムが提供されており、これを可能にします。これらのメカニズムの例としては、以下のようなものがあります。
std::ffi(さび)既存のラッパー ライブラリの例: