एडाप्टर पैटर्न: क्लीन कोड गाइड (TypeScript)

विवरण: रियल-वर्ल्ड TypeScript उदाहरणों से एडाप्टर पैटर्न सीखें — असंगत APIs जोड़ना, लेगेसी रिफैक्टरिंग, और स्केलेबल इंटीग्रेशन।

परिचय

एडाप्टर डिज़ाइन पैटर्न असंगत सिस्टम्स को जोड़ने का सरल तरीका है। यह पैटर्न मौजूदा क्लासेस को बिना उनके स्रोत कोड को बदले सहयोग करने देता है और आपके एप्लिकेशन लॉजिक को बाहरी जटिलताओं से अलग रखता है। आज के वातावरण में, जहाँ तृतीय-पक्ष लाइब्रेरी और लेगेसी सर्विसेज आम हैं, एडाप्टर पैटर्न साफ़, रखरखाव योग्य आर्किटेक्चर का आधार बनता है¹।

क्यों आपके प्रोजेक्ट को एडाप्टर पैटर्न चाहिए

जब आप थर्ड‑पार्टी APIs या पुराने सिस्टम्स के साथ काम करते हैं, तो असंगत इंटरफेसेज़, कोड डुप्लिकेशन, और हाई कपलिंग जैसी समस्याएँ बन जाती हैं। एडाप्टर एक समर्पित क्लास देता है जो अनुवाद का काम एक जगह संभालता है, जिससे कोर बिज़नेस लॉजिक साफ़ रहता है और इंटीग्रेशन मैनेज करना आसान होता है। यह रणनीति मॉड्यूलर आर्किटेक्चर और क्रमिक मॉडर्नाइज़ेशन के लिए उपयुक्त है²।

एडाप्टर पैटर्न केवल काम चलाने का तरीका नहीं है, यह आपके कोर एप्लिकेशन लॉजिक की सादगी और अखंडता की रक्षा करता है।³

एडाप्टर कैसे काम करता है

मुख्य खिलाड़ी:

• क्लाइंट: कोड जो एक सरल, स्थिर इंटरफ़ेस की उम्मीद करता है।
• टार्गेट: क्लाइंट द्वारा उपयोग किया जाने वाला अपेक्षित इंटरफ़ेस।
• एडाप्टी: मौजूदा कंपोनेंट जिसका इंटरफ़ेस असंगत है।
• एडाप्टर: टार्गेट को इम्प्लिमेंट करता है और कॉल्स को एडाप्टी के अनुरूप अनुवादित करता है।

यह डिजाइन ओपन/क्लोज्ड सिद्धांत के साथ मेल खाता है: नए सर्विस जोड़ने के लिए क्लाइंट को छुए बिना नया एडाप्टर लिखें¹.

TypeScript में वास्तविक उदाहरण

नीचे दो व्यावहारिक उदाहरण दिए गए हैं: एक लेगेसी XML API का अनुवाद और एक थर्ड‑पार्टी पेमेंट गेटवे का स्टैंडर्डाइज़ेशन।

उदाहरण 1 — लेगेसी XML API को JSON में अनुवाद करना

परिस्थिति: आपका फ्रंट‑एंड JSON अपेक्षित करता है, लेकिन उपलब्ध सर्विस XML लौटाती है। क्लाइंट IUserService का उपयोग करेगा; LegacyUserService XML देता है। एडाप्टर इनके बीच पुल बनाता है।

// Adaptee: पुराना सर्विस जो XML रिटर्न करता है
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>
    `;
  }
}

// Target इंटरफ़ेस और 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();
    // प्रोडक्शन में मजबूत XML पार्सर का उपयोग करें, जैसे xml2js
    console.log("Translating XML to JSON...");
    // यहाँ पार्सिंग लॉजिक होगा; उदाहरण स्वरूप हार्डकोडेड रिटर्न
    return [
      { id: 1, name: "Alice", email: "alice@example.com" },
      { id: 2, name: "Bob", email: "bob@example.com" },
    ];
  }
}

यह एडाप्टर क्लाइंट को IUserService के माध्यम से XML विवरणों से स्वतंत्र रखता है।

उदाहरण 2 — थर्ड‑पार्टी पेमेंट गेटवे को स्टैंडर्ड करना

परिस्थिति: आपका एप IPaymentProcessor इंटरफ़ेस इस्तेमाल करता है, पर PayWizard गेटवे के मेथड अलग हैं। एडाप्टर आपका स्टैण्डर्ड कॉल्स PayWizard के अनुरूप बदल देगा।

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;
  }
}

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);
  }
}

एडाप्टर के साथ आपका एप्लिकेशन विभिन्न प्रोवाईडर्स के बीच सुसंगत रहता है।

लेगेसी कोड को एडाप्टर से रिफैक्टर करना

एडाप्टर आपको बड़े जोखिम भरे रीराइट के बजाय चरणबद्ध माइग्रेशन की सुविधा देता है। यह रणनीति एंटरप्राइज़ वातावरण में आम है, जहाँ पुराने सिस्टम अभी भी महत्वपूर्ण होते हैं⁴।

चरण-दर-चरण माइग्रेशन प्लान

1. अपने आदर्श Target इंटरफ़ेस को परिभाषित करें।
2. एक Adapter क्लास बनाएं जो उस इंटरफ़ेस को लागू करे और एडाप्टी को स्वीकार करे।
3. अनुवाद लॉजिक को एडाप्टर में लागू करें।
4. क्लाइंट को क्रमिक रूप से एडाप्टर पर माइग्रेट करें।

AI टूल्स बॉयलरप्लेट बनाने में मदद कर सकते हैं, पर महत्वपूर्ण मैपिंग और आर्किटेक्चरल निर्णय टीम का काम रहेगा⁵।

पैटर्न्स के बीच चयन

एडाप्टर, डेकोरेटर, प्रॉक्सी और फैसाद कभी‑कभी समान दिखते हैं लेकिन अलग उद्देश्यों के लिए हैं:

• एडाप्टर: इंटरफ़ेस को बदलता है।
• डेकोरेटर: व्यवहार जोड़ता है, इंटरफ़ेस बनाए रखता है।
• प्रॉक्सी: पहुँच नियंत्रित करता है या रिसोर्स मैनेजमेंट करता है।
• फैसाद: सबसिस्टम को सरल बनाता है।

टीम में एडाप्टर लागू करने के दिशानिर्देश

• दस्तावेज़ीकरण: हर एडाप्टर के लिए README लिखें जिसमें Adaptee, Target और मैपिंग स्पष्ट हो।
• टेस्टिंग: यूनिट टेस्ट आवश्यक हों जो अनुवाद लॉजिक सत्यापित करें।
• प्रदर्शन निगरानी: जो एडाप्टर हॉट पाथ में हैं उन्हें बेंचमार्क करें।

CI में चेक जोड़ें ताकि एडाप्टर्स कंसिस्टेंट रहें और आंतरिक डॉक में टेम्पलेट उपलब्ध कराएँ।

संक्षेप में: कब एडाप्टर बेहतर है

एडाप्टर तब उपयोगी है जब मौजूद कंपोनेंट ठीक काम कर रहा हो पर इंटरफ़ेस मेल नहीं खाता, खासकर उन सिस्टम्स के साथ जिन्हें आप नियंत्रित नहीं करते। अगर कंपोनेंट में बग्स हैं या वह आवश्यक फीचर्स नहीं देता, तब री-राइट पर विचार करें।

तीन संक्षिप्त Q&A (अक्सर पूछे जाने वाले प्रश्न)

Q: एडाप्टर रिफैक्टरिंग की तुलना में कब चुनना चाहिए?

A: जब मौजूदा सिस्टम स्थिर और विश्वसनीय हो पर उसका इंटरफ़ेस अनुकूल न हो, तब एडाप्टर तेज़ और कम जोखिम वाली विकल्प है।

Q: क्या एडाप्टर परफ़ॉर्मेंस समस्या बनता है?

A: सामान्य व्यवसायिक एप्स में एडाप्टर से जुड़ा ओवरहेड नगण्य होता है — अक्सर यह नेटवर्क या I/O लागत से छोटा होता है। लेटेंसी संवेदनशील पाथ में बेंचमार्क जरूर करें।

Q: टीम कैसे सुनिश्चित करे कि एडाप्टर ओवरयूस न हों?

A: एडाप्टर के लिए दिशानिर्देश, यूनिट टेस्ट, और README ज़रूरी करें; CI में ऑटो चेक्स और प्रदर्शन मानदंड रखें।

संदर्भ और फुटनोट्स