Mediator Tasarım Deseni Nedir?

Yazılım dünyasında, uygulamaların karmaşıklığı arttıkça, farklı bileşenler arasındaki iletişim yönetimi önemli bir zorluk haline gelir. Bir sistemdeki nesneler doğrudan birbirleriyle etkileşime girdiğinde, zamanla yoğun bir bağımlılık ağı oluşur. Bu durum, kodun anlaşılmasını, bakımını ve genişletilmesini son derece zorlaştırır. İşte tam da bu noktada, Mediator (Arabulucu) tasarım deseni devreye girerek bu karmaşıklığı yönetmek için zarif bir çözüm sunar.

Mediator Tasarım Deseni Nedir?

Mediator, davranışsal (behavioral) bir tasarım desenidir. Amacı, bir grup nesnenin (işbirlikçilerin) doğrudan birbirleriyle iletişim kurmasını engelleyerek, tüm iletişimi merkezi bir arabulucu (mediator) nesnesi üzerinden gerçekleştirmektir. Böylece, nesneler arasındaki bağımlılıklar azalır ve her nesne yalnızca arabulucuyla etkileşime girer. Bu, sistemin daha gevşek bağlı (loosely coupled) ve daha kolay yönetilebilir olmasını sağlar.

Temel Bileşenler

Mediator deseninin temel olarak dört ana bileşeni vardır:

1. Mediator (Arabulucu) Arayüzü: İşbirlikçi nesnelerin arabulucu ile iletişim kurmak için kullanacağı metotları tanımlar. Bu, genellikle bir arayüz veya soyut bir sınıf olabilir.
2. ConcreteMediator (Somut Arabulucu): Mediator arayüzünü uygular ve işbirlikçi nesneler arasındaki iletişimi yöneten gerçek mantığı içerir. Hangi işbirlikçinin hangi olaya nasıl tepki vereceğini bilir ve iletişimi orkestra eder.
3. Colleague (İşbirlikçi) Arayüzü/Soyut Sınıfı: Arabulucu ile iletişim kuracak nesneler için ortak bir arayüz veya soyut sınıf tanımlar. Her işbirlikçi, arabulucuya bir referans tutar.
4. ConcreteColleague (Somut İşbirlikçi): Colleague arayüzünü uygular. Kendi iç mantığını barındırır ve iletişim kurması gerektiğinde arabulucuya başvurur, doğrudan diğer işbirlikçilerle etkileşime geçmez.

Bu yapı sayesinde, bir işbirlikçi nesnesindeki bir değişiklik, diğer işbirlikçi nesneleri doğrudan etkilemek yerine, yalnızca arabulucu üzerinden yansıtılır. Arabulucu, iletişimin merkezi noktası olduğu için, tüm iletişim mantığı tek bir yerde toplanır.

Mediator Ne Zaman Kullanılır ve Avantajları/Dezavantajları Nelerdir?

Kullanım Senaryoları

Mediator deseni, özellikle aşağıdaki durumlarda oldukça faydalıdır:

• Kullanıcı Arayüzleri (UI): Karmaşık formlar veya diyalog pencereleri üzerinde birden fazla UI bileşeninin (düğmeler, metin kutuları, onay kutuları vb.) birbiriyle etkileşime girmesi gerektiğinde. Örneğin, bir onay kutusu işaretlendiğinde bazı metin kutularının etkinleştirilmesi veya bir düğmeye basıldığında birden fazla alanın doğrulanması.
• Sohbet Uygulamaları: Bir sohbet odasındaki kullanıcıların doğrudan birbirleriyle değil, sohbet odası sunucusu (arabulucu) aracılığıyla mesajlaşması.
• Hava Trafik Kontrolü: Uçakların (işbirlikçilerin) doğrudan birbirleriyle değil, hava trafik kontrol kulesi (arabulucu) aracılığıyla iletişim kurması.
• İş Akışları (Workflows): Bir iş akışındaki farklı adımların veya bileşenlerin birbirleriyle koordineli çalışması gerektiğinde, ancak doğrudan bağımlılık istenmediğinde.
• Birden Fazla Nesnenin Karmaşık Etkileşimleri: Sistemin karmaşıklığı, nesnelerin doğrudan iletişim kurmasının anlaşılması ve sürdürülmesi zor bir “spagetti kod” ağına yol açtığında.

Avantajları

• Azaltılmış Bağlılık (Reduced Coupling): İşbirlikçiler yalnızca arabulucuya bağlıdır, birbirlerine değil. Bu, bir işbirlikçide yapılan bir değişikliğin diğerlerini etkileme olasılığını azaltır.
• Merkezi İletişim Kontrolü: Tüm iletişim mantığı tek bir yerde (arabulucuda) toplandığı için, sistemin davranışını anlamak ve değiştirmek daha kolay hale gelir.
• Yeniden Kullanılabilirlik: İşbirlikçi nesneler, diğer işbirlikçilerle doğrudan bağlantıları olmadığı için farklı bağlamlarda daha kolay yeniden kullanılabilir.
• Bakım Kolaylığı: İletişim kurallarında yapılan değişiklikler, yalnızca arabulucu sınıfında yapılır, bu da sistemin bakımını basitleştirir.
• Tek Sorumluluk İlkesi (Single Responsibility Principle): İşbirlikçi nesneler kendi iş mantıklarına odaklanırken, arabulucu iletişim mantığına odaklanır.

Dezavantajları

• Arabulucu “Tanrı Nesnesi” (God Object) Olabilir: Eğer iletişim mantığı çok karmaşık hale gelirse, arabulucu sınıfı çok büyük ve yönetilemez hale gelebilir. Tüm sistemin yükünü taşıyan bir “tanrı nesnesi” haline gelme riski vardır.
• Soyutlama Katmanı: Ek bir soyutlama katmanı getirdiği için, basit iletişim senaryolarında gereksiz karmaşıklık yaratabilir.
• Performans Etkisi: Her iletişimin arabulucu üzerinden geçmesi, çok yüksek performans gerektiren sistemlerde küçük bir performans ek yüküne neden olabilir.

Java’da Mediator Deseni Uygulaması: Bir Sohbet Odası Örneği

Şimdi, Mediator deseninin Java’da nasıl uygulanabileceğini, klasik bir sohbet odası örneği üzerinden inceleyelim. Bu örnekte, kullanıcılar doğrudan birbirlerine mesaj göndermek yerine, bir sohbet odası (arabulucu) aracılığıyla iletişim kuracaklardır.

1. Mediator Arayüzü: ChatRoom

Sohbet odasının iletişim metotlarını tanımlayan arayüz.

// Mediator Arayüzü
interface ChatRoom {
    void sendMessage(String message, User user);
    void addUser(User user);
}

2. Colleague Soyut Sınıfı: User

Sohbet odasındaki kullanıcıları temsil eden soyut sınıf. Her kullanıcı bir arabulucuya (sohbet odasına) referans tutar.

// Colleague Soyut Sınıfı
abstract class User {
    protected ChatRoom mediator;
    protected String name;

    public User(ChatRoom mediator, String name) {
        this.mediator = mediator;
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void send(String message) {
        System.out.println(name + " sends: " + message);
        mediator.sendMessage(message, this);
    }

    public abstract void receive(String message);
}

3. ConcreteMediator Sınıfı: ChatRoomImpl

ChatRoom arayüzünü uygulayan somut arabulucu sınıfı. Kullanıcıları yönetir ve mesajların dağıtımını yapar.

import java.util.ArrayList;
import java.util.List;

// ConcreteMediator Sınıfı
class ChatRoomImpl implements ChatRoom {
    private List users;

    public ChatRoomImpl() {
        this.users = new ArrayList<>();
    }

    @Override
    public void addUser(User user) {
        this.users.add(user);
        System.out.println(user.getName() + " joined the chat room.");
    }

    @Override
    public void sendMessage(String message, User sender) {
        // Mesajı gönderen hariç tüm kullanıcılara ilet
        for (User user : users) {
            if (user != sender) { // Gönderen kendine mesaj almasın
                user.receive(sender.getName() + ": " + message);
            }
        }
    }
}

4. ConcreteColleague Sınıfı: ChatUser

User soyut sınıfını uygulayan somut işbirlikçi sınıfı. Mesajları nasıl alacağını tanımlar.

// ConcreteColleague Sınıfı
class ChatUser extends User {
    public ChatUser(ChatRoom mediator, String name) {
        super(mediator, name);
    }

    @Override
    public void receive(String message) {
        System.out.println(name + " received: " + message);
    }
}

5. Uygulama (Main Metodu)

Mediator deseninin nasıl çalıştığını gösteren ana program.

// Main Uygulama
public class MediatorPatternDemo {
    public static void main(String[] args) {
        // 1. Bir sohbet odası (Mediator) oluştur
        ChatRoom chatRoom = new ChatRoomImpl();

        // 2. Kullanıcılar (Colleagues) oluştur
        User user1 = new ChatUser(chatRoom, "Alice");
        User user2 = new ChatUser(chatRoom, "Bob");
        User user3 = new ChatUser(chatRoom, "Charlie");

        // 3. Kullanıcıları sohbet odasına ekle
        chatRoom.addUser(user1);
        chatRoom.addUser(user2);
        chatRoom.addUser(user3);

        System.out.println("\n--- Sohbet Başlıyor ---");

        // 4. Kullanıcılar mesaj gönderir (Mediator aracılığıyla)
        user1.send("Merhaba millet!");
        System.out.println();
        user2.send("Selam Alice, nasılsın?");
        System.out.println();
        user3.send("Ben de buradayım!");
    }
}

Çıktı

Alice joined the chat room.
Bob joined the chat room.
Charlie joined the chat room.

--- Sohbet Başlıyor ---
Alice sends: Merhaba millet!
Bob received: Alice: Merhaba millet!
Charlie received: Alice: Merhaba millet!

Bob sends: Selam Alice, nasılsın?
Alice received: Bob: Selam Alice, nasılsın?
Charlie received: Bob: Selam Alice, nasılsın?

Charlie sends: Ben de buradayım!
Alice received: Charlie: Ben de buradayım!
Bob received: Charlie: Ben de buradayım!

Bu örnekte, ChatUser nesneleri birbirlerini doğrudan tanımıyor ve mesajları doğrudan birbirlerine göndermiyor. Bunun yerine, her ChatUser nesnesi, mesaj göndermesi gerektiğinde ChatRoom nesnesine başvuruyor. ChatRoom ise mesajı alan diğer kullanıcıları belirleyip onlara iletiyor. Bu sayede, kullanıcılar arasındaki bağımlılık ChatRoom nesnesine indirgenmiş oluyor.

Sonuç ve Sıkça Sorulan Sorular (SSS)

Mediator tasarım deseni, karmaşık nesne etkileşimlerini basitleştirerek, yazılım sistemlerinin daha az bağımlı, daha kolay bakımı yapılabilir ve daha esnek olmasını sağlayan güçlü bir araçtır. Özellikle büyük ve çok bileşenli uygulamalarda, iletişim karmaşasını önlemek için merkezi bir kontrol noktası sunar. Ancak, arabulucunun bir “tanrı nesnesi” haline gelme riskine karşı dikkatli olmak ve gerektiğinde farklı desenlerle birleştirmek önemlidir.

Sıkça Sorulan Sorular (SSS)

1. Mediator ile Observer deseni arasındaki fark nedir?

• Mediator: İşbirlikçiler arasındaki iletişimi doğrudan yönetir ve orkestra eder. İşbirlikçiler birbirlerini bilmez, yalnızca arabulucuyu bilirler. Arabulucu, hangi işbirlikçinin hangi mesaja nasıl tepki vereceğini belirler. Daha çok “tek yönlü” bir kontrol ve yönlendirme söz konusudur.
• Observer: Bir “subject” (konu) nesnesinin durumundaki değişiklikleri “observer” (gözlemci) nesnelerine bildirir. Subject, kendisini gözlemleyen observer’ları doğrudan bilmez, sadece bir değişiklik olduğunda onları uyarır. Observer’lar, subject’ten gelen bildirimlere kendi bağımsız mantıklarına göre tepki verirler. Daha çok “yayınla-abone ol” modelidir.
• Kısaca: Mediator, iletişimi yönetir; Observer, değişiklikleri bildirir.

2. Ne zaman Mediator yerine nesneler arasında doğrudan iletişim kurmak daha iyidir?

• Eğer yalnızca iki veya üç nesne arasında basit ve sınırlı bir etkileşim varsa, Mediator deseni gereksiz karmaşıklık yaratabilir.
• İletişim mantığı çok basit ve değişme olasılığı düşükse, doğrudan iletişim daha anlaşılır olabilir.
• Performans kritik uygulamalarda, arabulucunun getireceği küçük ek yük bile istenmeyebilir.

3. Mediator’ın “Tanrı Nesnesi” olmasını nasıl engellerim?

• Sorumlulukları Böl: Eğer arabulucu çok fazla sorumluluk üstleniyorsa, bu sorumlulukları daha küçük arabuluculara veya yardımcı sınıflara bölmeyi düşünün.
• Diğer Desenleri Kullan: Mediator içinde Command, Strategy veya State gibi diğer desenleri kullanarak karmaşık mantığı modüler hale getirebilirsiniz.
• İletişimi Sınırla: Arabulucunun tüm olası iletişim senaryolarını ele almasını beklemeyin. Sadece gerçekten merkezi olması gereken iletişimi yönetmesine izin verin.

4. Spring gibi framework’lerde Mediator deseni nasıl kullanılır veya nereye karşılık gelir?

• Spring’in doğrudan bir “Mediator” bileşeni olmasa da, Spring IoC (Inversion of Control) konteyneri ve bağımlılık enjeksiyonu (DI) mekanizması, Mediator deseninin ruhuna uygun gevşek bağlı sistemler oluşturmanıza yardımcı olur.
• Örneğin, bir Spring servisi, farklı bileşenleri (repository’ler, diğer servisler, dış API’ler) bir araya getirerek karmaşık bir iş akışını yönetiyorsa, bu servis bir tür “iş akışı arabulucusu” rolü üstleniyor olabilir. Bu servis, çeşitli bileşenleri birbirine bağlar ve aralarındaki etkileşimi koordine eder, ancak doğrudan bağımlılıkları Spring’in DI mekanizması yönetir.
• Spring Event mekanizması, Observer desenine daha yakın olsa da, bazen belirli bir olay tipi için birden fazla dinleyicinin koordinasyonunu gerektiren durumlarda, olay gönderici (publisher) ve dinleyiciler (listeners) arasında bir “işlem arabulucusu” rolü üstlenen bir Spring bileşeni tasarlayabilirsiniz.