Adapter tasarım deseni esasen bir aracı katmandır. İki uyumsuz sistemin sorunsuzca konuşmasını sağlayan bir çevirmen gibi düşünün. Amaç, mevcut sınıfları orijinal kaynak kodlarına hiç dokunmadan işbirliği yapar hale getirmektir. Bu, Kanadalı elektronik cihazınızı Avrupa prizine takmanızı sağlayan seyahat adaptörünün yazılım eşdeğeridir.

Bu desen, özellikle üçüncü taraf bir kütüphaneyi entegre etmeye ya da miras (legacy) bir sistemi idare etmeye çalışırken temiz, sürdürülebilir kodun temel taşlarından biridir.¹

Neden Kod Tabanınız Adapter Desenine İhtiyaç Duyar

Şunu hayal edin: Avrupa'dasınız ve Kanadalı dizüstü bilgisayarınızı duvardaki prize takmaya çalışıyorsunuz. Hiç oturmuyor. Şarj cihazınız düzgün çalışıyor, duvardaki priz düzgün çalışıyor, ama arayüzleri tamamen farklı. Yazılım geliştirmede tam da bu sorun sık sık ortaya çıkar; hiç tasarlanmamış iki sistemin aniden birlikte çalışması gerekir.

İşte Adapter deseni burada devreye girer. Kod için evrensel seyahat adaptörünüzdür; uyumsuz bileşenler arasında sorunsuz bir köprü yaratır.

Modern Geliştirmede Uçurumu Kapatmak

Bugün nadiren her şeyi sıfırdan inşa ediyoruz. Çözümleri üçüncü taraf kütüphaneler, harici API'ler ve miras sistemlerden bir araya getiriyoruz. Bu, teslimatı hızlandırır ama uyumsuz arayüzler ve uzun vadede acı veren cazip kestirme yollar yaratır:

• Kod tekrarları: aynı çeviri mantığı uygulama genelinde dağılır.
• Yüksek bağlılık: iş mantığı harici servis detaylarıyla karışır.
• Artan teknik borç: her API değişikliği kırılgan entegrasyon kodunda bir hazine avı başlatır.

Adapter deseni, çeviriyi tek bir yerde ele alan özel bir adapter sınıfı sağlar; böylece temel uygulama mantığınızı korur ve entegrasyonları daha kolay bakım yapılabilir hale getirir. Bu yaklaşım, modüler mimariye ve kademeli modernizasyona öncelik veren ekiplerde yaygındır.²

Adapter deseni sadece işleri çalıştırmak için bir hile değildir. Harici sistemlerin karışık detaylarından çekerek temel uygulama mantığınızın sadeliğini ve bütünlüğünü korur.

Adapterler Temiz ve Ölçeklenebilir Kodu Teşvik Eder

Bir adapter, tamamen yeniden yazmaya ihtiyaç duymadan değişebilen esnek bir mimari kurmanın stratejisidir. Servisleri değiştirebilir veya miras sistemleri devre dışı bırakmayı, istemci koduna dokunmak yerine adapter ekleyerek veya değiştirerek yapabilirsiniz. Bu istikrar özellik geliştirmeyi hızlandırır ve entegrasyon riskini azaltır.²

Adapter Deseni Gerçekte Nasıl Çalışır

Desenin özü, sistem parçaları arasında temiz bir ayrım yaratarak bağımsız evrilmelerini sağlar. Bu deseni anlamayı kolaylaştıran dört oyuncu vardır:

1. İstemci (Client): bir şey yaptırması gereken ve basit, stabil bir arayüz bekleyen kod.
2. Hedef (Target): İstemci'nin konuştuğu temiz arayüz.
3. Adaptee: uyumsuz arayüze sahip mevcut bileşen (genellikle değiştirilemez).
4. Adapter: Target'i uygular ve çağrıları Adaptee'ye çevirir.

İstemci yalnızca Target arayüzü ile konuşur; Adapter sessizce Adaptee için çeviri yapar. Bu tasarım Açık/Kapalı (Open/Closed) Prensibi ile iyi örtüşür: yeni bir servis entegre etmek için yeni bir adapter yazarak mevcut istemci kodunu dokunmadan bırakabilirsiniz.¹

Adapter deseninin birincil amacı, bir sınıfın arayüzünü istemcilerin beklediği başka bir arayüze dönüştürmektir. Adapter, uyumsuz arayüzler yüzünden birlikte çalışamayan sınıfların birlikte çalışmasına izin verir.³

Gerçek Örneklerle TypeScript'te Adapter İnşa Etmek

Aşağıda, gerçek dünyada sık karşılaşılan iki sorunu yansıtan pratik TypeScript örnekleri bulunuyor: miras bir XML API'sini adapte etme ve üçüncü taraf bir ödeme sağlayıcısını standartlaştırma.

Örnek 1: Miras XML API'yi JSON'a Uydurmak

Senaryo: modern React frontend'iniz JSON bekliyor, ancak tek veri kaynağı XML döndüren bir miras servis. İstemci temiz bir IUserService arayüzü kullanmalı; LegacyUserService ise XML ile konuşuyor. Adapter bunları birbirine bağlar.

Uyumsuz Adaptee

// Adaptee: The old service with an incompatible interface
class LegacyUserService {
  fetchUsersXML(): string {
    return `
      <users>
        <user id="1">
          <name>Alice</name>
          <email>alice@example.com</email>
        </user>
        <user id="2">
          <name>Bob</name>
          <email>bob@example.com</email>
        </user>
      </users>
    `;
  }
}

Hedef Arayüz ve Adapter

interface IUser {
  id: number;
  name: string;
  email: string;
}

interface IUserService {
  getUsers(): Promise<IUser[]>;
}

class UserServiceAdapter implements IUserService {
  private adaptee: LegacyUserService;

  constructor(legacyService: LegacyUserService) {
    this.adaptee = legacyService;
  }

  async getUsers(): Promise<IUser[]> {
    const xmlData = this.adaptee.fetchUsersXML();
    // Use a robust XML parser in production (e.g., xml2js).
    console.log("Translating XML to JSON...");
    return [
      { id: 1, name: "Alice", email: "alice@example.com" },
      { id: 2, name: "Bob", email: "bob@example.com" },
    ];
  }
}

Bu adapter ile istemci kodu IUserService ile konuşur ve XML'den bağımsız kalır.

Örnek 2: Üçüncü Taraf Ödeme Geçidini Standardize Etmek

Senaryo: uygulamanız standart bir IPaymentProcessor arayüzü kullanıyor, ancak PayWizard geçidi startTransaction ve verifyPaymentStatus gibi yöntemlere sahip. Adapter standart çağrılarınızı PayWizard'ın API'sine eşler.

Tutarsız Adaptee

class PayWizard {
  startTransaction(amount: number, cardDetails: string): string {
    console.log(`PayWizard: Initiating transaction for $${amount}.`);
    const transactionId = "pw_" + Math.random().toString(36).substr(2, 9);
    return transactionId;
  }

  verifyPaymentStatus(transactionId: string): boolean {
    console.log(`PayWizard: Verifying status for ${transactionId}.`);
    return true;
  }
}

Hedef Arayüz ve Adapter

interface IPaymentProcessor {
  processPayment(amount: number, cardInfo: string): Promise<string>;
  checkStatus(id: string): Promise<boolean>;
}

class PayWizardAdapter implements IPaymentProcessor {
  private payWizard: PayWizard;

  constructor() {
    this.payWizard = new PayWizard();
  }

  async processPayment(amount: number, cardInfo: string): Promise<string> {
    console.log("Adapter: Translating 'processPayment' to 'startTransaction'.");
    return this.payWizard.startTransaction(amount, cardInfo);
  }

  async checkStatus(id: string): Promise<boolean> {
    console.log("Adapter: Translating 'checkStatus' to 'verifyPaymentStatus'.");
    return this.payWizard.verifyPaymentStatus(id);
  }
}

Adapterleri kullanmak, uygulama kodunuzu farklı sağlayıcılar arasında temiz ve tutarlı tutar.

Miras Kodu Adapterlerle Refaktör Etmek

Her proje er ya da geç miras kodla karşılaşır. Adapter deseni, eski sistemleri modern bir Target arayüzü ile sarmalayarak ve istemci kodunu kademeli olarak taşıyarak riskli büyük yeniden yazımlardan kaçınmanıza izin verir. Bu yaklaşım riski azaltır ve kontrollü bir modernizasyon planını destekler.²

Adım Adım Bir Göç Planı

1. İdeal Target arayüzünüzü tanımlayın.
2. Bu arayüzü uygulayan ve miras Adaptee'yi kabul eden Adapter sınıfını oluşturun.
3. Çeviri mantığını adapter içinde uygulayın.
4. İstemci kodunu kademeli olarak Adapter kullanacak şekilde taşıyın.

AI ile Refaktörü Hızlandırma

Modern yapay zeka araçları boilerplate işleri hızlandırabilir; böylece kritik eşleme mantığına odaklanabilirsiniz, ancak mimari kararlar ekip sorumluluğu olarak kalır. Adapterleri iskeletlendirmek için araçları kullanın ve ardından eşlemeleri doğrulayan testler yazın.

Bir adapter kullanmak sadece geçici bir düzeltme değil; kademeli modernizasyona olanak tanıyan mimari sağlığa yapılan stratejik bir yatırımdır.²

Adapter ile Diğer Desenler Arasında Seçim Yapmak

Doğru deseni seçmek önemlidir. Adapter, Decorator, Proxy ve Façade benzer görünebilir ama farklı amaçlara hizmet eder. Arayüzleri değiştirmek için Adapter'ı, davranış eklemek için Decorator'ı, erişimi kontrol etmek için Proxy'yu, karmaşık alt sistemleri basitleştirmek için Façade'i kullanın.

Adapter vs Decorator

Adapter bir arayüzü çevirir. Decorator orijinal arayüzü korurken sorumluluklar ekler.

Adapter vs Proxy

Proxy aynı arayüzü korur ve erişimi kontrol eder veya tembel başlatma, önbellekleme ya da logging ekler. Adapter, istemcinin aksi takdirde uyumsuz olan bir bileşeni kullanabilmesi için arayüzü değiştirir.

Adapter vs Façade

Façade, bir alt sistemi tek bir arayüzün arkasında basitleştirir. Adapter, iki bileşenin birlikte çalışabilmesi için tek bir nesnenin arayüzünü dönüştürmeye odaklanır.

Adapter Desenini Ekibinize Getirmek

Aşırı kullanımdan kaçınmak için adapter oluşturma konusunda net sınırlar koyun:

• Dokümantasyon: her adapter, Adaptee'yi, Target arayüzünü ve eşlemeyi belirten bir README'ye sahip olmalı.
• Test: çeviri mantığını doğrulayan birim testleri zorunlu kılın.
• Performans izleme: kritik adapterler sıcak yol üzerindeyse bunları benchmark edin.

Bu kuralları CI'da zorlamak için otomatik kontroller ekleyin ve adapterleri kod tabanı genelinde tutarlı tutun. Dahili doküman sitenizde örnekler ve şablonlar sağlayın ya da modernizing legacy systems gibi kılavuzlara bağlantı verin.

Sorularınız mı Var? Hadi Adapterleri Konuşalım

Soru & Cevap

S: Bir adapter, tam bir yeniden yazımdan ne zaman daha iyidir?

C: Mevcut bileşen çalışıyorsa ancak arayüzü ihtiyaçlarınızla uyuşmuyorsa—özellikle kontrolünüzde olmayan stabil miras sistemler veya üçüncü taraf API'ler için—adapter kullanın. Bileşen hatalıysa veya gerekli özelliklerden yoksunsa, yeniden yazım düşünülebilir.

S: Adapterler fark edilir performans yükü ekler mi?

C: Adapterler küçük bir yük ekler—ekstra bir metod çağrısı veya bir dönüşüm adımı—ancak çoğu iş uygulamasında bu, ağ veya I/O maliyetlerine kıyasla gözardı edilebilir. Gecikmeye duyarlı sistemlerde adapteri benchmark edin.

S: Ekibim adapterleri nasıl test etmeli?

C: Target ile Adaptee arasındaki eşleme üzerine odaklanan birim testleri yazın. Gerekli yerlerde Adaptee'yi mock'layın ve adapterin gerçek bağımlılık ile doğru davrandığını doğrulayan entegrasyon testleri ekleyin.