メディエータパターンは、ソフトウェア開発においてオブジェクト間の通信を管理するためのデザインパターンです。複雑なシステムにおいて、オブジェクト同士が直接通信すると依存関係が増え、メンテナンスが難しくなります。そこで、メディエータパターンを用いることで、各オブジェクトが中央のメディエータ（仲介者）とだけ通信するようにし、依存関係を減らします。本記事では、C++を用いたメディエータパターンの実装方法や応用例について詳しく解説します。
メディエータパターンとは
メディエータパターンは、オブジェクト間の直接的な通信を避け、中央に配置された「メディエータ」が通信の仲介を行うデザインパターンです。このパターンを使用することで、オブジェクト同士の依存関係が減少し、システムの柔軟性と拡張性が向上します。メディエータパターンは、複数のオブジェクトが互いに通信する必要があるが、その相互依存を最小限に抑えたい場合に特に有効です。
メディエータパターンの構造
メディエータパターンは、以下の主要なコンポーネントで構成されます：
メディエータ (Mediator)
メディエータは、オブジェクト間の通信を仲介する役割を果たします。すべての通信はメディエータを通じて行われ、オブジェクト間の直接的な通信はありません。
コリーグ (Colleague)
コリーグは、メディエータを通じて他のコリーグと通信するオブジェクトです。コリーグはメディエータの存在を知っており、メディエータを介してメッセージを送受信します。
クラス図
以下のクラス図は、メディエータパターンの基本構造を示しています。
+-----------------+ +-----------------+ +-----------------+
| Mediator | <------> | ConcreteColleague1 |
|-----------------| |-----------------| |-----------------|
| +notify() | | +send() | | +send() |
| +addColleague() | | +receive() | | +receive() |
+-----------------+ +-----------------+ +-----------------+
^ ^ ^
| | |
| | |
+-----------------+ +-----------------+ +-----------------+
| ConcreteMediator| | ConcreteColleague2 | ConcreteColleagueN|
|-----------------| |-----------------| |-----------------|
| -colleagues | | +send() | | +send() |
| +notify() | | +receive() | | +receive() |
| +addColleague() | | | | |
+-----------------+ +-----------------+ +-----------------+通信の流れ
コリーグがメッセージを送信する場合、そのメッセージはメディエータに送られ、メディエータが適切なコリーグにメッセージを転送します。この方法により、コリーグ間の直接的な依存関係を排除します。
C++でのメディエータパターンの実装例
ここでは、C++を用いてメディエータパターンを実装する具体例を紹介します。まず、メディエータとコリーグの基本インターフェースを定義し、その後具体的なクラスを実装します。
メディエータインターフェース
#include <iostream>
#include <vector>
#include <string>
class Colleague;
class Mediator {
public:
virtual void notify(Colleague* sender, const std::string& event) = 0;
virtual void addColleague(Colleague* colleague) = 0;
};コリーグインターフェース
class Colleague {
protected:
Mediator* mediator;
public:
Colleague(Mediator* mediator) : mediator(mediator) {}
virtual void send(const std::string& message) = 0;
virtual void receive(const std::string& message) = 0;
};具体的なメディエータクラス
class ConcreteMediator : public Mediator {
private:
std::vector<Colleague*> colleagues;
public:
void notify(Colleague* sender, const std::string& event) override {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(event);
}
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
};具体的なコリーグクラス
class ConcreteColleague : public Colleague {
private:
std::string name;
public:
ConcreteColleague(Mediator* mediator, const std::string& name) : Colleague(mediator), name(name) {}
void send(const std::string& message) override {
std::cout << name << " sends: " << message << std::endl;
mediator->notify(this, message);
}
void receive(const std::string& message) override {
std::cout << name << " receives: " << message << std::endl;
}
};メイン関数での実装例
int main() {
ConcreteMediator* mediator = new ConcreteMediator();
ConcreteColleague* colleague1 = new ConcreteColleague(mediator, "Colleague1");
ConcreteColleague* colleague2 = new ConcreteColleague(mediator, "Colleague2");
mediator->addColleague(colleague1);
mediator->addColleague(colleague2);
colleague1->send("Hello, World!");
colleague2->send("Hi there!");
delete colleague1;
delete colleague2;
delete mediator;
return 0;
}この実装例では、ConcreteMediatorがメディエータの役割を果たし、ConcreteColleagueが通信を行うコリーグの役割を果たします。各コリーグはメッセージを送信し、メディエータを介して他のコリーグにメッセージが転送されます。これにより、コリーグ間の直接的な依存関係を減らし、コードの柔軟性と拡張性を向上させることができます。
メディエータパターンの応用例
メディエータパターンは、さまざまなシナリオで有効に活用できます。以下にいくつかの応用例を示します。
チャットアプリケーション
メディエータパターンは、チャットアプリケーションでのユーザー間のメッセージ交換を管理するために使用できます。各ユーザー（コリーグ）はメディエータにメッセージを送信し、メディエータが他のすべてのユーザーにメッセージを配信します。
class ChatMediator : public Mediator {
public:
void notify(Colleague* sender, const std::string& message) override {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(message);
}
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
};GUIコンポーネントの相互作用
GUIアプリケーションでは、ボタン、テキストフィールド、リストなどのコンポーネント間の相互作用をメディエータパターンで管理できます。例えば、ボタンをクリックするとテキストフィールドの内容が更新されるような場合に、メディエータがこれらの通信を仲介します。
class GUIComponent : public Colleague {
public:
GUIComponent(Mediator* mediator) : Colleague(mediator) {}
void send(const std::string& event) override {
mediator->notify(this, event);
}
void receive(const std::string& event) override {
std::cout << "Component received: " << event << std::endl;
}
};航空管制システム
航空管制システムでは、各航空機がメディエータ（航空管制官）を介して相互に通信することで、衝突を回避し、効率的なフライト運行を実現します。
class Aircraft : public Colleague {
public:
Aircraft(Mediator* mediator) : Colleague(mediator) {}
void send(const std::string& status) override {
mediator->notify(this, status);
}
void receive(const std::string& status) override {
std::cout << "Aircraft received status: " << status << std::endl;
}
};これらの例は、メディエータパターンがどのようにさまざまなシステムで通信を効率化し、依存関係を管理するために使用できるかを示しています。パターンを適用することで、システムの設計がよりシンプルかつ柔軟になり、メンテナンスが容易になります。
メディエータパターンのメリットとデメリット
メリット
依存関係の減少
メディエータパターンを使用すると、オブジェクト間の直接的な依存関係が減少し、システム全体の柔軟性が向上します。これにより、各オブジェクトはメディエータにのみ依存するようになり、他のオブジェクトの変更が最小限に抑えられます。
可読性とメンテナンス性の向上
オブジェクト間の複雑な通信をメディエータが一元的に管理するため、コードの可読性とメンテナンス性が向上します。各オブジェクトが独自に通信を処理するのではなく、メディエータを通じて行うため、通信の流れが明確になります。
再利用性の向上
メディエータパターンを使用すると、コリーグオブジェクトは他のコリーグと独立して動作するため、再利用が容易になります。新しいコリーグを追加する場合でも、既存のオブジェクトに変更を加える必要がほとんどありません。
デメリット
メディエータの複雑化
すべての通信をメディエータが処理するため、メディエータ自身が複雑化し、肥大化する可能性があります。これにより、メディエータがボトルネックとなり、メンテナンスが難しくなることがあります。
パフォーマンスの低下
すべての通信を中央のメディエータを介して行うため、直接通信に比べてパフォーマンスが低下する場合があります。特に、高頻度の通信が必要な場合やリアルタイム性が求められるシステムでは注意が必要です。
単一障害点の発生
メディエータがシステムの中心となるため、メディエータに障害が発生した場合、システム全体が影響を受ける可能性があります。このため、メディエータの信頼性と可用性を確保するための対策が必要です。
これらのメリットとデメリットを考慮し、メディエータパターンを適用するかどうかを判断することが重要です。適切に使用すれば、システムの設計がシンプルかつ柔軟になり、メンテナンスが容易になる一方で、適用が不適切である場合、パフォーマンスや複雑性の問題が生じる可能性があります。
メディエータパターンと他のデザインパターンの比較
メディエータパターン vs. オブザーバーパターン
共通点
- 目的: どちらのパターンもオブジェクト間の通信を管理し、依存関係を減らすために使用されます。
- 非直接的な通信: オブジェクトが他のオブジェクトと直接通信するのではなく、別のオブジェクト（メディエータまたはオブザーバー）を介して通信します。
相違点
- 構造: メディエータパターンでは、メディエータが中央の仲介者として機能し、すべての通信を管理します。オブザーバーパターンでは、サブジェクトが状態の変化を通知し、複数のオブザーバーがそれを受け取ります。
- 用途: メディエータパターンは、複数のオブジェクトが相互に通信する必要がある場合に使用されます。一方、オブザーバーパターンは、特定のオブジェクト（サブジェクト）の状態が変化したときに、その変化を他のオブジェクト（オブザーバー）に通知するために使用されます。
メディエータパターン vs. コマンドパターン
共通点
- 目的: 両パターンとも、オブジェクトの行動や通信を管理することを目的としています。
相違点
- 構造: メディエータパターンでは、メディエータが通信を管理し、各オブジェクトはメディエータを介して他のオブジェクトと通信します。コマンドパターンでは、コマンドオブジェクトが特定のアクションをカプセル化し、リシーバーにそのアクションを実行させます。
- 用途: メディエータパターンは、複数のオブジェクト間の複雑な通信を管理するために使用されます。コマンドパターンは、操作をオブジェクトとして扱い、操作の実行、取り消し、再実行を可能にするために使用されます。
メディエータパターン vs. ファサードパターン
共通点
- 目的: 両パターンとも、システムの複雑さを管理し、簡潔なインターフェースを提供することを目指しています。
相違点
- 構造: メディエータパターンでは、メディエータがオブジェクト間の通信を仲介します。ファサードパターンでは、ファサードがシステムの複雑なサブシステムへの簡単なインターフェースを提供します。
- 用途: メディエータパターンは、オブジェクト間の通信を管理するために使用されます。ファサードパターンは、複雑なサブシステムを隠蔽し、クライアントにシンプルなインターフェースを提供するために使用されます。
これらの比較を通じて、メディエータパターンがどのように他のデザインパターンと異なり、どのようなシナリオで最適に適用されるかを理解することが重要です。それぞれのパターンには独自の利点があり、特定の問題に対して適切なパターンを選択することが、効果的なソフトウェア設計につながります。
メディエータパターンを使ったプロジェクトの事例
航空交通管制システム
航空交通管制システムは、複数の航空機が安全に離着陸し、空域を飛行するための複雑な通信を必要とします。このシステムでは、メディエータパターンを用いることで、航空機間の直接的な通信を避け、航空管制官（メディエータ）がすべての通信を管理します。
システムの概要
航空機（コリーグ）は、自分の位置、速度、高度などの情報を管制官（メディエータ）に送信します。管制官は、受け取った情報をもとに各航空機に指示を出し、安全な航路を確保します。
class AirTrafficControl : public Mediator {
public:
void notify(Colleague* sender, const std::string& event) override {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(event);
}
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
};
class Aircraft : public Colleague {
public:
Aircraft(Mediator* mediator, const std::string& name) : Colleague(mediator), name(name) {}
void send(const std::string& message) override {
std::cout << name << " sends: " << message << std::endl;
mediator->notify(this, message);
}
void receive(const std::string& message) override {
std::cout << name << " receives: " << message << std::endl;
}
private:
std::string name;
};使用例
int main() {
AirTrafficControl* atc = new AirTrafficControl();
Aircraft* aircraft1 = new Aircraft(atc, "Aircraft1");
Aircraft* aircraft2 = new Aircraft(atc, "Aircraft2");
atc->addColleague(aircraft1);
atc->addColleague(aircraft2);
aircraft1->send("Requesting takeoff clearance.");
aircraft2->send("Descending to 10,000 feet.");
delete aircraft1;
delete aircraft2;
delete atc;
return 0;
}オンラインチャットシステム
オンラインチャットシステムでは、複数のユーザーがリアルタイムでメッセージをやり取りします。メディエータパターンを使用することで、各ユーザーのメッセージをチャットサーバー（メディエータ）が受け取り、他のユーザーに転送することができます。
システムの概要
ユーザー（コリーグ）は、メッセージをチャットサーバー（メディエータ）に送信します。チャットサーバーは、受信したメッセージを他のすべてのユーザーに転送し、リアルタイムでのコミュニケーションを実現します。
class ChatServer : public Mediator {
public:
void notify(Colleague* sender, const std::string& message) override {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(message);
}
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
};
class ChatUser : public Colleague {
public:
ChatUser(Mediator* mediator, const std::string& name) : Colleague(mediator), name(name) {}
void send(const std::string& message) override {
std::cout << name << " sends: " << message << std::endl;
mediator->notify(this, message);
}
void receive(const std::string& message) override {
std::cout << name << " receives: " << message << std::endl;
}
private:
std::string name;
};使用例
int main() {
ChatServer* server = new ChatServer();
ChatUser* user1 = new ChatUser(server, "User1");
ChatUser* user2 = new ChatUser(server, "User2");
server->addColleague(user1);
server->addColleague(user2);
user1->send("Hello everyone!");
user2->send("Hi User1!");
delete user1;
delete user2;
delete server;
return 0;
}これらの事例は、メディエータパターンがどのように実世界のアプリケーションで使用され、複雑な通信を管理し、システムの柔軟性と拡張性を向上させるかを示しています。
メディエータパターンのベストプラクティス
1. 明確なインターフェースを定義する
メディエータとコリーグのインターフェースを明確に定義し、各オブジェクトの役割を明確にします。これにより、コードの可読性と保守性が向上します。
例
class Mediator {
public:
virtual void notify(Colleague* sender, const std::string& event) = 0;
virtual void addColleague(Colleague* colleague) = 0;
};class Colleague {
protected:
Mediator* mediator;
public:
Colleague(Mediator* mediator) : mediator(mediator) {}
virtual void send(const std::string& message) = 0;
virtual void receive(const std::string& message) = 0;
};2. 単一責任の原則を遵守する
メディエータは通信の仲介に専念し、コリーグは自身のビジネスロジックに集中するように設計します。これにより、各クラスが単一の責任を持ち、変更が容易になります。
例
メディエータは通信の管理を行い、コリーグは自分のデータやロジックにのみ関与します。
class ChatMediator : public Mediator {
public:
void notify(Colleague* sender, const std::string& event) override {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(event);
}
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
};class User : public Colleague {
public:
User(Mediator* mediator, const std::string& name) : Colleague(mediator), name(name) {}
void send(const std::string& message) override {
std::cout << name << " sends: " << message << std::endl;
mediator->notify(this, message);
}
void receive(const std::string& message) override {
std::cout << name << " receives: " << message << std::endl;
}
private:
std::string name;
};3. 適切なエラーハンドリングを実装する
メディエータやコリーグ間の通信でエラーが発生した場合の処理を明確にします。これにより、予期しないエラーが発生した場合でも、システムが安定して動作します。
例
class SafeMediator : public Mediator {
public:
void notify(Colleague* sender, const std::string& event) override {
try {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(event);
}
}
} catch (const std::exception& e) {
std::cerr << "Error: " << e.what() << std::endl;
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
};4. コリーグの追加と削除を動的に管理する
システムの柔軟性を高めるために、コリーグの追加と削除を動的に管理できるようにします。これにより、システムが拡張や変更に対して柔軟に対応できるようになります。
例
class DynamicMediator : public Mediator {
public:
void notify(Colleague* sender, const std::string& event) override {
for (Colleague* colleague : colleagues) {
if (colleague != sender) {
colleague->receive(event);
}
}
}
void addColleague(Colleague* colleague) override {
colleagues.push_back(colleague);
}
void removeColleague(Colleague* colleague) {
colleagues.erase(std::remove(colleagues.begin(), colleagues.end(), colleague), colleagues.end());
}
};5. メディエータのテストを重視する
メディエータの動作をテストするためのユニットテストを作成し、メディエータが正しく通信を仲介していることを確認します。これにより、バグの発見と修正が容易になります。
例
void testMediator() {
DynamicMediator mediator;
Colleague* user1 = new User(&mediator, "User1");
Colleague* user2 = new User(&mediator, "User2");
mediator.addColleague(user1);
mediator.addColleague(user2);
user1->send("Hello, World!");
// Expected output:
// User1 sends: Hello, World!
// User2 receives: Hello, World!
delete user1;
delete user2;
}これらのベストプラクティスを遵守することで、メディエータパターンを効果的に実装し、システムの柔軟性、可読性、保守性を向上させることができます。
メディエータパターンのテスト方法
ユニットテストの作成
メディエータパターンを使用するシステムのユニットテストを作成することで、各コンポーネントが正しく動作し、通信が正しく仲介されることを確認します。ここでは、C++のテストフレームワークを使用して、メディエータパターンのテスト方法を紹介します。
テストフレームワークのセットアップ
C++のテストフレームワークとして、Google Test（gtest）を使用します。まず、gtestをプロジェクトに追加し、基本的なセットアップを行います。
#include <gtest/gtest.h>
#include "mediator.h" // メディエータパターンの実装ファイルをインクルード
class MockColleague : public Colleague {
public:
MockColleague(Mediator* mediator, const std::string& name) : Colleague(mediator), name(name) {}
void send(const std::string& message) override {
mediator->notify(this, message);
}
void receive(const std::string& message) override {
receivedMessage = message;
}
std::string getReceivedMessage() const {
return receivedMessage;
}
private:
std::string name;
std::string receivedMessage;
};メディエータのユニットテスト
メディエータが正しく動作するかどうかをテストします。具体的には、メディエータがメッセージを適切に仲介し、各コリーグに正しく配信するかを確認します。
TEST(MediatorTest, SingleMessageTest) {
ConcreteMediator mediator;
MockColleague colleague1(&mediator, "Colleague1");
MockColleague colleague2(&mediator, "Colleague2");
mediator.addColleague(&colleague1);
mediator.addColleague(&colleague2);
colleague1.send("Test Message");
EXPECT_EQ(colleague2.getReceivedMessage(), "Test Message");
}
TEST(MediatorTest, MultipleMessagesTest) {
ConcreteMediator mediator;
MockColleague colleague1(&mediator, "Colleague1");
MockColleague colleague2(&mediator, "Colleague2");
MockColleague colleague3(&mediator, "Colleague3");
mediator.addColleague(&colleague1);
mediator.addColleague(&colleague2);
mediator.addColleague(&colleague3);
colleague2.send("Hello from Colleague2");
EXPECT_EQ(colleague1.getReceivedMessage(), "Hello from Colleague2");
EXPECT_EQ(colleague3.getReceivedMessage(), "Hello from Colleague2");
}エッジケースのテスト
メディエータパターンのエッジケースをテストすることで、システムが予期しない状況でも正しく動作することを確認します。
コリーグなしでメッセージを送信する
コリーグが登録されていない状態でメッセージを送信した場合、エラーが発生しないかを確認します。
TEST(MediatorTest, NoColleaguesTest) {
ConcreteMediator mediator;
MockColleague colleague(&mediator, "Colleague");
EXPECT_NO_THROW(colleague.send("Message without colleagues"));
}コリーグの削除と再送信のテスト
コリーグが削除された後にメッセージを送信した場合、適切に処理されるかを確認します。
TEST(MediatorTest, RemoveColleagueTest) {
ConcreteMediator mediator;
MockColleague colleague1(&mediator, "Colleague1");
MockColleague colleague2(&mediator, "Colleague2");
mediator.addColleague(&colleague1);
mediator.addColleague(&colleague2);
mediator.removeColleague(&colleague2);
colleague1.send("Message after removal");
EXPECT_EQ(colleague2.getReceivedMessage(), "");
}統合テストの実施
ユニットテストだけでなく、システム全体の統合テストを実施することで、メディエータパターンがシステム全体で正しく機能することを確認します。統合テストでは、メディエータとコリーグが実際に連携して動作するシナリオをテストします。
TEST(MediatorIntegrationTest, FullSystemTest) {
ConcreteMediator mediator;
MockColleague colleague1(&mediator, "Colleague1");
MockColleague colleague2(&mediator, "Colleague2");
MockColleague colleague3(&mediator, "Colleague3");
mediator.addColleague(&colleague1);
mediator.addColleague(&colleague2);
mediator.addColleague(&colleague3);
colleague1.send("System check");
EXPECT_EQ(colleague2.getReceivedMessage(), "System check");
EXPECT_EQ(colleague3.getReceivedMessage(), "System check");
}これらのテスト方法を通じて、メディエータパターンが正しく実装されているか、またシステムが安定して動作するかを確認できます。テストを定期的に実施し、メディエータパターンの品質を維持することが重要です。
まとめ
本記事では、C++を用いたメディエータパターンの実装方法について詳しく解説しました。メディエータパターンは、オブジェクト間の通信を中央のメディエータが仲介することで、依存関係を減らし、システムの柔軟性と保守性を向上させるデザインパターンです。具体的な実装例や応用例、メリットとデメリット、他のデザインパターンとの比較、ベストプラクティス、テスト方法などを通じて、メディエータパターンの有用性とその効果的な活用方法を学びました。これにより、複雑なシステムの設計と管理がよりシンプルかつ効率的になることが期待できます。
コメント