Meditator パターンでフロントエンドのコンポーネント間の依存関係を整理する

Last updated at 2023-05-14Posted at 2021-12-28

はじめに

「Java で学ぶデザインパターン入門」を読んでいるときに、Meditator パターンを見つけました。このデザインパターンを使うと、コンポーネント間の依存関係が複雑に絡み合うことを防げると思い、Vue で実装してみました。

サンプルコードだけ知りたい方はこちらからどうぞ。

Meditator パターンとは

Meditator パターンでの主な登場人物は二人です。

Meditator

Colleague と通信を行なう
Colleague を操作するロジックを持つ

Colleague

Meditator と通信を行なう
基本的には Meditator にイベントを通知し、値を受け取り、描画するだけ
自分自身に閉じる view のロジックは持っても良い

以下のような流れで処理が進みます。

①：親である Meditator に子である Colleague がイベントを通知

②：Colleague からのイベントを元に Meditator でロジックを実行

③：Meditator の実行結果を Colleague に通知

④：必要に応じて Colleague は自身を再描画

Meditator パターンを採用するメリット

Meditator パターンを採用するメリットはロジックの集約だと思っています。ロジックを集約するレイヤー（Meditator）を作ることで、

機能の仕様を簡単に理解できる
コンポーネント間の依存関係が一方向になる（Meditator ⇄ Colleague）
コンパイルで発見できないロジックのバグを見つけやすくなる

というメリットを享受できます。

ログイン時にゲストとログインユーザーを切り替えるチェックボックスの例を考えます。Guest か Login かのどちらかしか選択できないとします。

Meditator パターンを採用しない場合

図の横方向（黄色）と縦方向（オレンジ）の両方向に矢印があることに注目してください。これは依存関係が複数方向にあることを意味しています。子コンポーネント間での値のやりとりを許した結果、親と子で値の整合性が取れなくなっています。これはコンパイル時にエラーにならないので非常に見つけにくいバグです。

では、子コンポーネント間の変更を親コンポーネントに通知し、親コンポーネントの値を変更すれば良いのではと思うかもしれません。しかし、子コンポーネントの量が増えた場合には、ロジックを追う際に見なくてはいけないファイル数がかなり増えます。実際の現場では、10個以上のファイルにロジックがまたがることもあります。そういった場合に、複数方向に依存性が絡み合ったコードを読み解き、仕様を理解するのはなかなか辛い作業で、ミスも発生するリスクが上がります。

Meditator パターンを採用する場合

図の矢印の向きが縦方向（オレンジ）のみであることに注目してください。これは依存関係が単方向であることを意味しており、ロジックによるバグがあった場合に見つけやすいです。また、ロジックが親であるログインフレームに集約されているので、ロジックを変更する際の影響範囲も一目瞭然です。ロジックが集約されているのでログイン機能の仕様も簡単に把握できます。新しく、ジョインする開発者にもここを見てと言えばいいのです。