0

デバイスとの通信を処理するクラスがあります。このクラスを Protocol と呼びました。クラスには状態情報が含まれていないため、プロトコル クラスのメソッドを公開し、デバイスの状態を含むモデル クラスを作成しました。

私が見ているように、これを実装するには3つの方法があります

  1. モデル クラスにプロトコルを継承させる
  2. モデル クラスにプロトコルを実装させる
  3. モデルがプロパティを介してプロトコルを公開できるようにする

プロトコルには、オプション 1 と 3 に反対するモデル クラスの実装者に公開しないほうがよいメソッドが含まれている可能性があります。

オプション 2 では、プロトコルから公開するものを選択できますが、ほとんどの機能は次のようなプロトコルへの呼び出しになります。

DoSomething()
{
    protocol.DoSomething();
}

「より良い」選択肢は何だと思いますか？

注意: 状態とプロトコルを分離する理由は、プロトコルが固定されておらず、外部要因に応じて変化する可能性があるためです。

4

2 に答える 2

1

それらの間の継承関係が本当に必要ですか？

interface IDevice
{
    // Some implementation
}

interface IProtocol : IDisposable
{
    void Open(IDevice device, string connection);
    void Close();
    void Send(object data);
    object Receive();
}
于 2013-04-07T19:19:56.253 に答える
0

私は過去にコマンド ハンドラー デザインと呼ばれるものをこのようなものに使用しました。これがどのように機能したかです。

すべての作業 (「.DoSomething()」と呼ばれるもの) を実行する CommandHandler クラス (コンポーネント、実際にはいくつかの協調クラスがありました) がありました。したがって、これは上記のプロトコル クラスと同じです。この CommandHandler クラス/component, しかしながら, プロトコルについて何も知りませんでした. 彼はネイティブ言語の構成要素 (あなたの場合は C# クラス/インターフェース) を使用して作業を行いました. その後, 変換の作業を行う 1 つまたは複数のプロトコル クラスが存在することになります.プロトコルを言語構成要素に変換し (たとえば、XML をメッセージ クラスに変換し、ストリームからバイナリ バイトをクラスに変換するなど)、デコードされたプロトコルからそのクラスのインスタンスを作成し、これらのインスタンスに引数を渡すことによって、コマンド ハンドラー コンポーネントの機能を実行します。プロトコルから派生したパラメーターからのメソッド。

コマンド ハンドラーに新しいプロトコルを実装するには、プロトコル クラスを作成し、必要なプロトコルを処理するようにします。これにより、他のプロトコルが行ったコマンド ハンドラー コンポーネントのインスタンスを作成してメソッドを呼び出し、コア機能が機能しないようにします。変化する。

これがあなたが探していたものであることを願っています。

于 2013-04-07T19:34:38.617 に答える