イベント駆動型プログラミング：いつ価値があるのか​​？

わかりました、この質問のタイトルは、イベントベースのプログラミングをいつ使用する必要があるかとほぼ同じです。しかし、上記の質問の答えは、私が直面している特定のケースでイベントを使用すべきかどうかを決定するのに役立ちませんでした。

私は小さなアプリケーションを開発しています。それはシンプルなアプリであり、その機能の大部分は基本的なCRUDです。

特定のイベント（特定のデータを変更する場合）で、アプリケーションはそのデータのローカルコピーをファイルに書き込む必要があります。これを実装する最善の方法についてはわかりません。できます：

• データが変更されたときにイベントを起動し、そのようなイベントに応答をバインド（ファイルを生成）します。または、オブザーバーパターンを実装します。それは不必要な複雑さのようです。
• データを変更するコードからファイル生成コードを直接呼び出します。はるかに単純ですが、依存関係をこのように設定するのは間違っているようです。つまり、アプリのコア機能（データを変更するコード）をその追加の特典（バックアップファイルを生成するコード）に結合するのは間違っているようです。ただし、このアプリは、そのカップリングが問題を引き起こすポイントまで進化しないことを知っています。

この場合の最善のアプローチは何ですか？

KISSの原則：Keep It Simple、愚かさ、またはYAGNIの原則：あなたはそれを必要としません。

次のようなコードを書くことができます。

void updateSpecialData() {
    // do the update.
    backupData();
}

または、次のようなコードを書くことができます。

void updateSpecialData() {
     // do the update.
     emit SpecialDataUpdated();
}

void SpecialDataUpdatedHandler() {
     backupData();
}

void configureEventHandlers() {
     connect(SpecialDataUpdate, SpecialDataUpdatedHandler);
}

別の方法でやるに足る理由がない場合は、より単純なルートに従ってください。イベント処理などの手法は強力ですが、コードの複雑さが増します。動作するにはより多くのコードが必要であり、コード内で発生することを追跡しにくくします。

適切な状況ではイベントは非常に重要です（イベントなしでUIプログラミングを試みることを想像してください！）。しかし、代わりにKISSまたはYAGNIできる場合は使用しないでください。

変更が何らかの効果を引き起こす単純なデータの例は、オブザーバーデザインパターンで完全に実装できます。

• これは、完全なイベント駆動型コードよりも実装および保守が簡単です。
• サブジェクトとオブザーバーの結合は抽象的である場合があり、懸念の分離を促進します。
• 1対多の関係に最適です（被験者には1人以上のオブザーバーがいます）。

イベント駆動型アプローチは、多対多のコンテキストで多くの異なる相互作用が発生する可能性がある場合、または連鎖反応が想定される場合（たとえば、サブジェクトがオブザーバーに通知し、場合によっては主題または他の主題）

あなたが言うように、イベントはクラス間の結合を減らす素晴らしいツールです。そのため、イベントの組み込みサポートなしで一部の言語で追加のコードを記述することができますが、全体像の複雑さは軽減されます。

イベントは間違いなくオブジェクト指向の最も重要なツールの1つです（Alan Kayによれば、オブジェクトはメッセージを送受信することで通信します）。イベントの組み込みサポートを備えた言語を使用する場合、または関数をファーストクラスの市民として扱う場合、それらを使用するのは簡単です。

サポートが組み込まれていない言語でさえ、Observerパターンのようなものの定型的な量はごくわずかです。すべてのアプリケーションで使用できるまともな汎用イベントライブラリをどこかで見つけて、ボイラープレートを最小限に抑えることができます。（汎用イベントアグリゲーターまたはイベントメディエーターは、ほとんどすべての種類のアプリケーションで役立ちます）。

小さなアプリケーションでは価値がありますか？私は間違いなくイエスと言うでしょう。

• クラスを相互に分離しておくと、クラスの依存関係グラフがきれいに保たれます。
• 具体的な依存関係のないクラスは、テスト内の他のクラスを考慮することなく、単独でテストできます。
• 具体的な依存関係のないクラスでは、完全なカバレッジを得るために必要な単体テストが少なくなります。

あなたにしている考え方は、場合、「それは本当にごく小さなアプリケーションですが、それは本当にそれほど重要ではありませんああけど」、考慮してください。

• 小さなアプリケーションは、後に大きなアプリケーションと組み合わされることがあります。
• 小規模なアプリケーションには、少なくとも他のアプリケーションで後で再利用する必要のあるロジックまたはコンポーネントが少なくとも含まれている可能性があります。
• 小規模なアプリケーションの要件は変更される可能性があり、リファクタリングが必要になります。これは、既存のコードを切り離すと容易になります。
• 後で追加機能を追加して、既存のコードを拡張する必要性を促すことができます。これは、既存のコードが既に分離されている場合もはるかに簡単です。
• 疎結合コードは一般に、密結合コードよりも書くのにそれほど時間はかかりません。ただし、密結合コードは、疎結合コードよりもリファクタリングとテストに時間がかかります。

全体として、アプリケーションのサイズは、クラスを疎結合に保つかどうかを決定する要因ではありません。SOLIDの原則は、大規模なアプリケーションだけでなく、あらゆる規模のソフトウェアとコードベースに適用できます。

実際、疎結合クラスを単体でテストするユニットで節約される時間は、それらのクラスの分離に費やされる追加の時間と釣り合うはずです。

オブザーバーパターンは、プログラミング言語が「コールバック」や「デリゲート」などをサポートしていると仮定して、Wikipediaの記事（またはGOFの本）で説明されているよりもはるかに小さい方法で実装できます。コールバックメソッドをCRUDコードに渡すだけです（オブザーバーメソッド。汎用の「ファイルへの書き込み」メソッドまたは空のメソッドのいずれかです）。「イベント発生」の代わりに、そのコールバックを呼び出すだけです。

結果として生成されるコードは、ファイル生成コードを直接呼び出すよりも複雑ですが、無関係なコンポーネントが密結合するという欠点はありません。

これにより、「YAGNI」のデカップリングを犠牲にすることなく、「両方の長所」を実現できます。