3

私は、サーバー、サーバープロセスにロードできるデバイスを制御するためのいくつかのプラグイン、およびサーバーに接続できるクライアントで構成される大規模なプロジェクトに取り組んでいます。最終的に存在する必要のあるフレームワークを構築するためのベストプラクティスを探しています。

クライアント、サーバー、プラグイン間で共有されるヘッダーファイルと、システムの各側面に固有のヘッダーがあります。ヘッダーは、クライアントとサーバー間、またはサーバーとプラグイン間でのみ共有される場合があります。同様に、プロジェクトの3つの側面すべてで共有できる共通のコードと、1つの特定の側面でのみ必要となるコードもあります。

プロジェクトが終了したら、サードパーティが開発できるようにクライアントアプリケーションとプラグイン開発者APIをリリースする必要があります。

これをサポートするために必要なフレームワークを適切に構成する方法がわかりません。

2つの別々のフレームワークが必要ですか?または、すべてのヘッダーを含み、2つの個別のdylibを提供する1つのフレームワークを持つことはできますか?

2つの別個のフレームワークが必要な場合、システムのすべての側面で共有されるヘッダーファイルをどのように処理しますか?バージョン管理で発生する可能性のある問題を回避するために、それらを各フレームワークにコピーしたくありません。

3番目のヘッダーのみのフレームワークは妥当なオプションでしょうか?

OS Xのフレームワークでこの種のものを構築するためのベストプラクティスを誰かが推奨できますか?

4

1 に答える 1

1

フレームワーク = ライブラリ +そのライブラリのヘッダー

各フレームワークには、公開するインターフェイスのヘッダー ファイルのみを含める必要があります。3 つのフレームワークすべてを構築するために共通のヘッダーが使用されたとしても、それらをバンドルする義務はありません。

フレームワークの 1 つが共通のヘッダーのみをバンドルし、ライブラリがまったくバンドルされていない場合でも、3 つのフレームワークのアプローチは問題ありません。例: Mac に Qt をインストールすると、多くのフレームワークに分割されていることがわかりますが、それらの間でヘッダーが重複することはありません。ヘッダーのみを含み、コードを含まないフレームワークもいくつかあります (たとえば、QtScript.framework)。

于 2011-06-08T17:41:01.593 に答える