デカップリングにインターフェイスの代わりにデリゲートを使用する。良いアイデア？

Question

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＃コードインタフェースは、デカップリングに適したアプローチですが、デリゲートを使用するこのアプローチは、関数型プログラミングに向いています。私は後続の開発者に、直感的なアプローチであることを黙って誓っているでしょうか？私は確かにインターフェイスではなく、デリゲートを使用してのプラス側を見ることができますが

Answer 1

これは興味深いアプローチです。あなたは二つのことに注意を払うようにしたいことがあります。

1. フィリップが述べたように、あなたが定義するためのメソッドの多くを持っているとき、あなたは大きなコンストラクタになってしまいます。これはクラス間の深い結合を引き起こします。1つ以上のまたはより少ない委任者は誰もが署名を変更するよう要求するでしょう。パブリックプロパティを作成し、いくつかのDIフレームワークを使用することを検討する必要があります。

2. メソッドレベルへの実装の中断は、時には細かすぎることがあります。クラス/インタフェースを使用すると、ドメイン/機能別にメソッドをグループ化できます。デリゲートをデリゲートに置き換えると、それらが混在して読み込み/保守が困難になることがあります。

ここでは、デリゲートの数が重要な要因と思われます。

Answer 2

、私はあなたの箇条書きの両方に反対する必要があります。

• 「それはより方法を模擬するためにはるかに簡単ですユニットテスト時のクラス "。 C＃のモックフレームワークのほとんどは、型を模倣するという考えのもとに構築されています。多くの人がメソッドをモックできますが、サンプルとドキュメント（およびフォーカス）は通常は型の周りにあります。 1つのメソッドでインターフェースをモックすることは、メソッドと同じように簡単にまたは簡単にモックすることができます。

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

私は、これは任意の手段によって悪いアプローチであるとは言わないよ - パッシング機能ではなく、種類は明らかにあなたがやっている状態ず、あなたのオブジェクトモデルの複雑さを軽減することができます。しかし、C＃では、あなたの次の開発者はこれを奇妙で混乱していると感じているでしょう（スキルレベルによって異なります）。オブジェクト指向とファンクショナルアプローチを混ぜることは、おそらくあなたが作業するほとんどの開発者から眉を上げているでしょう。