全部で約 10 の機能を備えた API が公開されているコンポーネントがあります。私はそれを達成するための2つの方法を考えることができます:
これらすべての機能を個別の機能として提供します。
XML を入力として受け取る関数を 1 つだけ公開します。指定された request_Type と XML で渡されたパラメーターに基づいて、それぞれの関数のいずれかを内部的に呼び出します。
Q1. 2 番目の設計は、最初の設計より疎結合になりますか?
コンポーネントを疎結合にする方法についていつも読んでいますが、実際にこの程度まで行って結合を失う必要がありますか?
Q2. これらのうちどれが OOP に関してより良い設計であり、その理由は?
編集：
この API を他のユーザーが使用できるように D-Bus 経由で公開している場合、型チェックは 2 つのアプローチを比較する際の考慮事項になりますか? 私が理解していることから、型チェックはコンパイル時に行われますが、この関数が一部の IPC で公開されている場合、型チェックの問題が発生しますか?
あなたが提案する2つの選択肢は、APIから提供したい「関数」の数（明らかに非常に多い）に違いはありません。ただし、強力な型チェックが失われているため、2番目の方法には多くの欠点があるようです。機能などを文書化するのがはるかに難しくなります（私が見る唯一の利点は、機能を追加する場合にAPIを変更する必要がないことです. ただし、実行時までユーザーが削除された関数などの API の変更を把握できないという欠点があります。)
この質問に関連するのは、単一責任の原則( http://en.wikipedia.org/wiki/Single_responsibility_principle ) です。OOPについて話しているので、1つのクラス内で数十の関数を公開するのではなく、それぞれが単一の責任を持つ異なるクラスに分割する必要があります. 適切な「責任」と役割を定義するにはある程度の練習が必要ですが、いくつかの基本的なガイドラインに従うことで、すぐに始めることができます。OOP の規則はありますか?を参照してください。良い出発点のために。
質問の編集に返信する
私は D-Bus を使ったことがないので、これは完全に間違っているかもしれません。しかし、私が読んだチュートリアルをざっと見ると
各オブジェクトは、1 つ以上のインターフェイスをサポートします。インターフェイスは、GLib、Qt、または Java と同様に、メソッドとシグナルの名前付きグループと考えてください。インターフェイスは、オブジェクト インスタンスの型を定義します。
DBus は、org.freedesktop.Introspectable のような単純な名前空間文字列でインターフェースを識別します。ほとんどのバインディングは、これらのインターフェース名を適切なプログラミング言語構造 (Java インターフェースや C++ 純粋仮想クラスなど) に直接マップします。
私が理解している限り、D-Bus には、いくつかのメソッドで構成されるインターフェイスを提供するさまざまなオブジェクトの概念があります。これは、（私にとって）上記の私の答えがまだ当てはまることを意味します。API を指定する「D-Bus ネイティブ」の方法は、インターフェイスを示すことを意味し、優れた OOP 設計ガイドラインが有効ではない理由はわかりません。D-Bus はこれらをネイティブ言語の構成要素にもマッピングしているように見えるため、これはさらに可能性が高くなります。
もちろん、XML で独自の API 記述言語を構築することを妨げる人は誰もいません。ただし、次のようなものは、基礎となる技術のある種の悪用です。そのようなことをするのには正当な理由が必要です。