不透明な構造体宣言を含むパブリックインターフェイスを備えたライブラリを設計しています。
lib_public.h：
typedef struct lib_struct lib_struct;
void foo(lib_struct *ptr);
void bar(lib_struct *ptr);
lib_structにそれを置くための悪いデザインのようですので、不透明な構造体は、OS固有の実装の詳細を隠しlib_struct.h、直接。しかし、私はまだそのメンバーを使用するユニットテストを書きたいと思っています。現在、構造体定義のみを含む別のプライベートヘッダーファイルを作成することにしました。
lib_struct_linux.h：
struct lib_struct{
int epoll;
int acceptor_socket;
}
したがって、実装lib_struct.cと単体テストlib_struct_test.cには、次のようにこのヘッダーが含まれます。
lib_struct.c：
#include "lib_struct_linux.h"
//function definition
lib_struct_test.c：
#include "lib_struct_linux.h"
//unit tests
構造体が1つのプライベートヘッダーファイル（lib_struct_linux.h）で定義され、構造体を操作する関数が別のパブリックヘッダーファイル（lib_public.h）で宣言されているという意味で、このような設計は厄介に見えます。そして、さらに別の実装ファイル（lib_struct.c）での関数の定義。
それは一般的なアプローチですか？いいえの場合、より良い方法でそれを設計することはどのように可能でしょうか。
はい、これはまったく問題ありません。
構造体が1つのプライベートヘッダーファイル（
lib_struct_linux.h）で定義され、構造体を操作する関数が別のパブリックヘッダーファイル（lib_public.h）で宣言されているという意味で、このような設計は厄介に見えます。そして、さらに別の実装ファイル（lib_struct.c）での関数の定義。
これを言い換えると、「パブリックインターフェイスはパブリックヘッダーにあり、実装のみの宣言はプライベートヘッダーにあり、実装はソースファイルにあります。」散らかっているようには聞こえませんが、実際、私には完全に良いデザインのように聞こえます。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加