4

GUI アプリを作成するときは、アプリケーションを「制御」または「調整」する最上位クラスを使用します。最上位クラスは、ネットワーク接続の初期化、アプリケーション全体の UI アクションの処理、構成ファイルのロードなどの調整を担当します。

GUI アプリ コントロールの特定の段階で、別のクラスに渡されます。たとえば、ユーザーが認証されると、メイン コントロールがログイン画面からデータ入力画面に切り替わります。さまざまなクラスは、最上位のコントロールが所有するオブジェクトの機能を使用する必要があります。以前は、オブジェクトを下位のコントロールに渡すか、インターフェイスを作成するだけでした。最近、オブジェクト全体ではなく、メソッド デリゲートを渡すように変更しました。主な理由は次の 2 つです。

  • 単体テストでは、クラスよりもメソッドをモックする方がはるかに簡単です。
  • 従属クラスが使用しているメソッドを正確にクラス コンストラクターで文書化することにより、コードが読みやすくなります。

簡略化されたコード例を以下に示します。

delegate bool LoginDelegate(string username, string password);
delegate void UpdateDataDelegate(BizData data);
delegate void PrintDataDelegate(BizData data);

class MainScreen {
    private MyNetwork m_network;
    private MyPrinter m_printer;

    private LoginScreen m_loginScreen;
    private DataEntryScreen m_dataEntryScreen;

    public MainScreen() {
        m_network = new Network();
        m_printer = new Printer();

        m_loginScreen = new LoginScreen(m_network.Login);
        m_dataEntryScreen = new DataEntryScreen(m_network.Update, m_printer.Print);
    }
}

class LoginScreen {
    LoginDelegate Login_External;

    public LoginScreen(LoginDelegate login) {
        Login_External = login
    }
}

class DataEntryScreen {
    UpdateDataDelegate UpdateData_External;
    PrintDataDelegate PrintData_External;

    public DataEntryScreen(UpdateDataDelegate updateData, PrintDataDelegate printData) {
        UpdateData_External = updateData;
        PrintData_External = printData;
    }
}

私の質問は、私はこのアプローチを好みますが、次の開発者はどのようにそれを見つけるのでしょうか? サンプルおよびオープン ソースの C# コード インターフェイスは、デカップリングの推奨されるアプローチですが、デリゲートを使用するこのアプローチは、関数型プログラミングに傾いています。後続の開発者が、彼らにとって直感に反するアプローチについて息を切らして罵倒する可能性はありますか?

4

2 に答える 2

2

興味深いアプローチです。次の 2 つの点に注意する必要があります。

  1. Philip が述べたように、定義するメソッドがたくさんあると、大きなコンストラクターになってしまいます。これにより、クラス間の深い結合が発生します。代理人が 1 人多かれ少なかれ、全員が署名を変更する必要があります。それらをパブリック プロパティにし、何らかの DI フレームワークを使用することを検討する必要があります。

  2. 実装をメソッド レベルに分割すると、細分化しすぎる場合があります。クラス/インターフェースを使用すると、ドメイン/機能によってメソッドをグループ化できます。それらをデリゲートに置き換えると、それらが混同されて読み取り/保守が難しくなる可能性があります。

ここでは代表者の数が重要な要素のようです。

于 2009-05-19T02:43:23.737 に答える
1

インターフェイスではなくデリゲートを使用することの肯定的な側面は確かにわかりますが、次の両方の箇条書きに反対する必要があります。

  • 「単体テストでは、クラスよりもメソッドをモックする方がはるかに簡単です」 . C# のほとんどのモック フレームワークは、型をモックするという考えに基づいて構築されています。多くはメソッドをモックできますが、サンプルとドキュメント (および焦点) は通常、型に関するものです。1 つのメソッドを使用してインターフェイスをモックすることは、メソッドをモックするのと同じくらい簡単です。

  • 「下位クラスが使用しているメソッドを正確にクラス コンストラクターに文書化することで、コードが読みやすくなります。」短所もあります-クラスが複数のメソッドを必要とすると、コンストラクターが大きくなります。従属クラスに新しいプロパティまたはメソッドが必要になると、インターフェイスを変更するだけでなく、それをチェーンのすべてのクラス コンストラクターに追加する必要があります。

これが決して悪いアプローチだと言っているわけではありません。型ではなく関数を渡すことで、何をしているのかが明確になり、オブジェクト モデルの複雑さを軽減できます。ただし、c# では、次の開発者はおそらくこれを奇妙または紛らわしいと見なすでしょう (スキル レベルによって異なります)。OO と関数型のアプローチを少しずつ組み合わせることは、少なくとも、一緒に仕事をするほとんどの開発者から眉をひそめられるでしょう。

于 2009-05-19T02:17:36.753 に答える