ノード:Library tips, 次:, 前:Versioning, 上:Top



インターフェース設計に対する助言

良いライブラリインターフェースと書くことは,多くの経験とライブラリが解 決する問題への完全な理解が必要です.

良いインターフェースを設計した場合,頻繁に変更する必要がなく,ドキュメ ントを更新し続ける必要がなく,ユーザはライブラリの使用方法を何度も学習 する必要がありません.

ここにライブラリインターフェースの設計に関するヒントの短いリストがあり, それは仕事上で役立つでしょう.

計画前
エントリポイントを頻繁に削除する必要がないように,すべてのインターフェー スを本当に最小限にするように試みてください.
インターフェースの変更を避ける
エントリポイントの再設計と変更を地獄のように繰り返すのが好きな人もいま す(注意:関数の名前変更はエントリポイントの変更と考えられます). インターフェースを再設計する必要がある場合,ユーザが既存のコードを書き 換える必要がないように,互換機能を残すことを試みてください.
不透明なデータ型の使用
ライブラリユーザがアクセスするデータ型の定義は,少ないければ少ないほど 良いでしょう.可能な場合,一般的な(内部データにキャスト可能な)ポインタ を受け入れる関数を設計し,ライブラリユーザが直接データを操作するのを許 可するのではなく,アクセスする関数を提供してください.そうすることで, インターフェースを変更せずに,データ構造を変更することが自由になります.

これは,本質的にオブジェクト指向のシステムで抽象的なデータ型と継承を使 用するのと同じです.

ヘッダファイルの使用
ライブラリのグローバル関数と変数のそれぞれのドキュメントをヘッダファイ ルに注意して書いていて,ライブラリソースファイルに含めている場合,コン パイラは偶然にインターフェースの変更の有無を知らせるでしょう(see C header files).
可能な場所でのstaticキーワード(またはその等価物)の使用
ライブラリが持つグローバル関数は,減らせば減らすほど,より柔軟に変更で きます.スタティック関数と変数は,形式を変更したいとき変更できます ...ユーザはそれらにアクセスできず,そのためインターフェースは変更 されません.
配列の次元に対する注意
大域的な配列の要素数は,たとえヘッダでextern int foo[];と宣言し ていたとしても,それはインターフェースの一部です.これはi386とその他の SVR4/ELFシステムでは,アプリケーションが共有ライブラリのデータを参照す る時,データのサイズ(と型)はアプリケーションの実行形式に含められます. 配列や文字列の大きさを変更したくなければ,配列ではなくポインタとして提 供してください.