C# インターフェースでのルーズカップリング — Tim Coreyのレッスン16での解説

フォームの配線は簡単 — 正しく配線することはそうではありません

1:18で、ティムはCreate PrizeとCreate Team UI要素の配線を始めます。 彼は、他のフォームを呼び出すのが難しいわけではなく、データを正しく戻すことが通常の失敗箇所であるので、このステップが威圧的に感じられることをすぐに指摘します。

ティムは、追加のフォームを開くことが挑戦ではないと説明します — その部分は簡単です。 挑戦は、一つのフォームがもう一つのフォームにどのようにして長期的な設計問題を作ることなく通信するかにあります。 ここで、依存関係ではなく契約を定義するというアイデアが重要になり始めます。

タイトカップリングの誘惑

1:34前後、ティムは明示的に一般的な間違いを指摘します: Create TournamentフォームをCreate Prizeフォームに直接結びつけることです。 このアプローチでは、一つのクラスがどの他のクラスと話しているかを正確に知っています。

ティムは、これがタイトカップリングを生み出し、フォームが相互に直接依存することを意味すると説明します。 一つのフォームが変われば、もう一方にも影響が及びます。 プログラムの他の部分が後で同じ機能を望む場合、それを再利用することはできません。

彼は、これがコンパイルされて動作するかもしれないが、特に大規模なシステムやプロフェッショナルな環境では、長期的な設計選択としては良くないと強調します。

コードを書く前にステップで考える

2:02で、ティムは一旦立ち止まり、コードに飛び込む代わりにステップを書き出します。 彼は次のリストを作ります:

1. Create Prizeフォームを呼び出す

2. PrizeModelを戻す

3. それを選択された賞品リストに追加する

ティムは、ステップを最初に書くことが論理エラーを防ぎ、コードの意図を明確にするのに役立つと説明します。 この構造化された思考はインターフェースが導入された時に特に重要になります。なぜならインターフェースは起こるべき事を定義し、その方法は定義しないからです。

参照タイプと戻り値が常に必要になるわけではない理由

4:56前後、ティムはモデルが渡されるときの重要な詳細を説明します。 彼は視聴者に、オブジェクトのコピーではなくアドレスを渡していることを思い出させます。

賞品がデータコネクタを通して保存される時、モデルには既にそのIDが埋め込まれています。 ティムは、インスタンスが既に変更されているために、モデルを再度戻すことがしばしば不要であると指摘します。

これは、インターフェースがデータを盲目的に移動するために存在するのではなく、完了と責任を示すために存在することを強化します。

モデルを最初に渡すことが悪い考えである理由

6:42で、ティムは同じインスタンスを共有するためにPrizeModelをフォームコンストラクタに渡すというアイデアを論じます。

彼はこの方法が実際の使用例で失敗する理由を説明します。ユーザーがフォームをキャンセルする場合、リストに空のままの、または無効な賞品が残ることになります。ティムは、クラスがインスタンスデータを共有できるからといって、共有するべきではないことを示します。

この瞬間は、インターフェイスが行動を定義し、データの保存を定義しないという考えを強化します。

呼び出し側のフォームを直接渡すことは悪い

7:46頃、Timは他の一般的なアプローチを取り上げ、Create Tournament Form全体をCreate Prize Formに渡し、SavePrizeのような公開メソッドを呼び出すことについて話します。

Timはこれがさらに悪い理由を説明します：

• 賞品フォームは、どのクラスがそれを呼び出しているかを正確に知っている

• 他の関係のないクラスは賞品フォームを再利用できない

• クラスは単一の使用ケースにロックされる

彼はこれをタイトカップリングと明示して呼び、これを避けるべきだと言います。

契約としてのインターフェイスの導入

9:01にTimは解決策であるインターフェイスを紹介します。

彼はinterfaceキーワードを使って新しいインターフェイスを作成し、それをIPrizeRequesterと名付けます。 Timは視聴者にインターフェイスの説明をします：

• クラスではない

• 具体的なメソッドを含まない

• 契約を定義するために存在する

インターフェイスは単一のメソッドを含んでいます：

• PrizeComplete(PrizeModel model)

Timはこのメソッドが何が起こるべきかを定義し、どのように起こるべきかは定義しないと説明します。

インターフェイスメンバーと責任

9:40にTimは、このインターフェイスを実装する誰もがそのメソッドをサポートすることに同意することを説明します。 インターフェースはデフォルトで公開メンバーを持ち、インスタンスデータを宣言しません。

ここでは、インターフェイスがストレージではなく能力を定義することをTimが明らかにします。 実装クラスがメソッドが呼ばれたときに何をするかを決定します。

クラスではなくインターフェイスタイプを渡す

10:19に、TimはCreate Prize Formのコンストラクタを修正し、具体的なフォームではなくIPrizeRequesterを受け取るようにします。

彼はこれが意味することを説明します：

• 誰かがフォームを呼び出すだろう

• フォームはそれが誰であるかを知らない

• 唯一の要件は、呼び出し元がインターフェイスを実装していることです

これは実際の緩い結合です。賞品フォームは特定のクラスではなくインターフェイスタイプに依存しています。

後で使用するためにインターフェイスインスタンスを保存する

11:06にTimはクラスレベルでインターフェイスインスタンスを保存します。 彼は、コンストラクターパラメータは保存されない限り、コンストラクター内だけに存在することを説明します。

これは、賞品フォームがボタンクリックイベント内で後でPrizeCompleteを呼び出すことを可能にします。

実装クラスを呼び戻す

11:49にTimは重要な瞬間を実演します：

callingForm.PrizeComplete(model);

彼は賞品フォームがインターフェイスを実装した誰かに戻って呼び、言っていると説明します：

"私は終わった、そしてここに完成したモデルがあります。"

この呼び出しの後にのみフォームは閉じます。 これにより、作成が成功した場合にのみ賞品が追加されることが保証されます。

トーナメントフォームでのインターフェースの実装

13:29に、TimはCreate Tournament Formに切り替え、インターフェイスを実装します。

彼は13:58のthisキーワードについて説明し、それを現在のインスタンス、つまりメモリ内の実際のオブジェクトと説明します。 これを渡すことにより、フォームはそのアドレスを渡しますが、インターフェイス契約を通じてのみです。

複数のインターフェイス、一つのクラス

18:41にTimは2つ目のインターフェイス、ITeamRequesterを紹介します。

彼は、クラスは1つの基底クラス（Formのような）からだけ継承できるが、複数のインターフェイスを実装できると説明します。 これにより、単一のクラスが、複数継承なしで複数の無関係な動作をサポートできるようになります。

Timは、インターフェイスはコードを持ち込まないが、必要なメソッドのみを定義すると強調します。

パターン、一貫性、エラー検出

42:08近くで、Timはパターンを使用することが重要な理由について振り返ります。 同じインターフェースベースの構造を繰り返すと、欠落したステップを明らかにし、デバッグが容易になります。

Timは、すべてを頭に抱えておこうとせずに、物事を書き留め、一貫したパターンを使用することを勧めます。 彼によれば、優れたデザインは完璧さではなく、明確さ、構造、将来の変更を簡単にすることです。

結論

レッスン16で、Tim Coreyは実際のWinFormsユースケースを使用して、インターフェイスがどのように緩やかな結合を可能にするかを示します。 抽象的な例に頼るのではなく、彼はインターフェースがどのように：

• 契約を定義します

• クラスを分離します

• 単一クラスで複数のインターフェイスをサポートします

• タイトカップリングを防ぎます

• 長期的な柔軟性を向上させます

レッスンの最後までに、アプリケーションはただ動作するだけではなく、成長、再利用、明確さをサポートするように構成されています。 Timのアプローチは、インターフェイスを実践的で目的のある、そして実際のC#開発には欠かせないものと感じさせます。

これらのインターフェイスと緩やかな結合の概念を実際にエンドツーエンドで使用した完全なアプリケーションについては、すべてのステップが実装され、テストされ、動作するC#アプリケーション内で改善されたレッスン16のビデオを視聴してください。