در مقاله قبل با Singleton Pattern آشنا شدیم؛ Patternی که به ما کمک می کرد تعداد Instanceهای یک کلاس را کنترل کنیم.

حالا سراغ یکی دیگر از معروف ترین اعضای خانواده Creational Patterns می رویم: Factory Method Pattern.

اما قبل از اینکه ببینیم Factory Method چیست، بهتر است مثل همیشه از خود Pattern شروع نکنیم.

اول مسئله را ببینیم.

مسئله؛ وقتی new کردن تبدیل به وابستگی می شود

فرض کنید در حال توسعه بخش پرداخت یک فروشگاه اینترنتی هستیم.

در نسخه اول پروژه فقط یک درگاه پرداخت داریم:

class ZarinpalGateway {
  pay(amount: number): void {
    console.log(`Pay ${amount} using Zarinpal`)
  }
}

const gateway = new ZarinpalGateway()

gateway.pay(500_000)

همه چیز ساده است.

اما چند ماه بعد تصمیم می گیریم درگاه دیگری هم اضافه کنیم.

مثلاً Stripe.

class StripeGateway {
  pay(amount: number): void {
    console.log(`Pay ${amount} using Stripe`)
  }
}

حالا بر اساس تنظیمات یا انتخاب کاربر باید تصمیم بگیریم کدام Gateway ساخته شود.

اولین راه حل احتمالاً چیزی شبیه این است:

function createPaymentGateway(type: string) {
  if (type === 'zarinpal') {
    return new ZarinpalGateway()
  }

  if (type === 'stripe') {
    return new StripeGateway()
  }

  throw new Error('Unsupported payment gateway')
}

هنوز هم مشکل خاصی دیده نمی شود.

دو Gateway داریم و یک شرط ساده.

اما پروژه رشد می کند.

درگاه های جدید اضافه می شوند:

Zarinpal
Stripe
PayPal
NextPay
IDPay

حالا همان کد ساده کم کم بزرگ تر می شود.

function createPaymentGateway(type: string) {
  if (type === 'zarinpal') {
    return new ZarinpalGateway()
  }

  if (type === 'stripe') {
    return new StripeGateway()
  }

  if (type === 'paypal') {
    return new PayPalGateway()
  }

  if (type === 'nextpay') {
    return new NextPayGateway()
  }

  if (type === 'idpay') {
    return new IDPayGateway()
  }

  throw new Error('Unsupported payment gateway')
}

اما حتی طولانی شدن ifها هم مشکل اصلی ما نیست.

مشکل اصلی جای دیگری است.

مشکل واقعی چیست؟

فرض کنید فقط Payment Service مسئول ساخت Gateway بود.

در این صورت شاید همین کد هم قابل تحمل بود.

اما در یک پروژه واقعی ممکن است بخش های مختلف سیستم به Payment Gateway نیاز داشته باشند.

مثلاً:

Checkout Service (سرویس ثبت و نهایی سازی خرید)
Refund Service (سرویس بازپرداخت وجه)
Subscription Service (سرویس اشتراک)
Invoice Service (سرویس صدور فاکتور)

اگر هر کدام مستقیماً بنویسند:

new ZarinpalGateway();

یا:

new StripeGateway();

یک وابستگی مستقیم بین منطق اصلی برنامه و پیاده سازی مشخص Gateway ایجاد کرده ایم.

برای مثال:

class CheckoutService {
  checkout(): void {
    const gateway = new ZarinpalGateway();

    gateway.pay(500_000);
  }
}

CheckoutService دیگر فقط مسئول Checkout نیست.

این کلاس حالا باید بداند:

از چه Payment Gatewayای استفاده می کنیم.
کلاس آن Gateway چیست.
چطور باید ساخته شود.
برای ساخته شدن به چه Dependencyهایی نیاز دارد.

فرض کنید فردا تصمیم بگیریم زرین پال را با درگاه دیگری جایگزین کنیم.

حالا باید تمام قسمت هایی را پیدا کنیم که نوشته اند:

new ZarinpalGateway();

و آن ها را تغییر دهیم.

هرچه پروژه بزرگ تر شود، این وابستگی دردسر بیشتری ایجاد می کند.

مسئله new نیست

اینجا باید یک سوءتفاهم مهم را برطرف کنیم.

new بد نیست.

Factory Method هم Patternی برای حذف new از برنامه نیست.

اگر یک کلاس ساده داریم و دقیقاً می دانیم چه چیزی باید ساخته شود، استفاده مستقیم از new کاملاً طبیعی است.

مثلاً:

const user = new User();

هیچ دلیلی ندارد فقط برای حرفه ای تر به نظر رسیدن کد، برای آن Factory بسازیم.

مشکل زمانی شروع می شود که تصمیم درباره نوع Object و نحوه ساخت آن وارد منطق اصلی برنامه شود.

یعنی Checkout نباید مجبور باشد بداند:

«برای پرداخت باید از ZarinpalGateway یک Instance بسازم.»

Checkout فقط باید بداند:

«من یک Payment Gateway می خواهم.»

این دو نگاه تفاوت مهمی دارند.

❌ راه حل اول؛ if و switch همه جا

یکی از رایج ترین راه حل ها این است که انتخاب کلاس را در همان جایی انجام دهیم که به Object نیاز داریم.

مثلاً:

class CheckoutService {
  checkout(type: string): void {
    let gateway

    switch (type) {
      case 'zarinpal':
        gateway = new ZarinpalGateway()
        break

      case 'stripe':
        gateway = new StripeGateway()
        break

      default:
        throw new Error('Unsupported payment gateway')
    }

    gateway.pay(500_000)
  }
}

این کد کار می کند.

اما Checkout حالا دو مسئولیت دارد:

مدیریت فرآیند Checkout
تصمیم گیری درباره ساخت Payment Gateway

اگر همین منطق در Refund و Subscription هم تکرار شود، مشکل بزرگ تر می شود.

با اضافه شدن هر Gateway جدید باید چندین قسمت از سیستم را تغییر دهیم.

❌ راه حل دوم؛ ساختن Object قبل از استفاده

ممکن است بگوییم Gateway را بیرون می سازیم و به Service می دهیم.

const gateway = new ZarinpalGateway();
const checkout = new CheckoutService(gateway);

این کار Coupling داخل CheckoutService را کمتر می کند و در بسیاری از مواقع اتفاقاً راه حل خوبی است.

اما هنوز یک سؤال باقی می ماند:

چه کسی باید تصمیم بگیرد کدام Gateway ساخته شود؟

اگر نوع Object در Runtime تغییر کند یا هر بخش از برنامه براساس شرایط خودش به پیاده سازی متفاوتی نیاز داشته باشد، همچنان باید مسئولیت ساخت آن را جایی مدیریت کنیم.

اینجاست که مفهوم Factory وارد بازی می شود.

ایده Factory چیست؟

ایده اولیه بسیار ساده است:

کدی که از یک Object استفاده می کند، لزوماً نباید مسئول ساختن آن هم باشد.

Checkout Service باید با مفهوم Payment Gateway کار کند، نه با جزئیات ساخت Zarinpal یا Stripe.

بنابراین ابتدا یک Contract مشترک تعریف می کنیم:

interface PaymentGateway {
  pay(amount: number): void;
}

سپس هر Gateway این Contract را پیاده سازی می کند.

class ZarinpalGateway implements PaymentGateway {
  pay(amount: number): void {
    console.log(`Pay ${amount} using Zarinpal`);
  }
}

class StripeGateway implements PaymentGateway {
  pay(amount: number): void {
    console.log(`Pay ${amount} using Stripe`);
  }
}

از دید کدی که قرار است پرداخت را انجام دهد، دیگر مهم نیست Object واقعی از چه کلاسی ساخته شده است.

تنها چیزی که اهمیت دارد این است که با PaymentGateway سازگار باشد.

این اولین قدم مهم است:

وابسته شدن به Contract به جای Implementation مشخص.

اما هنوز باید کسی تصمیم بگیرد کدام Implementation ساخته شود.

و دقیقاً از همین نقطه به Factory Method Pattern می رسیم.

Factory Method Pattern چیست؟

تا اینجا دیدیم که مشکل اصلی خود new نیست. مشکل زمانی شروع می شود که بخشی از برنامه که قرار است از یک Object استفاده کند، مجبور باشد بداند دقیقاً چه Objectی و از چه کلاسی باید ساخته شود.

Factory Method یکی از Creational Patternهاست که کمک می کند مسئولیت ساخت Object را از کدی که قرار است از آن استفاده کند جدا کنیم.

برگردیم به مثال درگاه پرداخت.

بدون Factory، ممکن است Checkout Service مستقیماً این کار را انجام دهد:

const gateway = new ZarinpalGateway();

gateway.pay(500_000);

در این حالت Checkout Service دقیقاً می داند که قرار است از ZarinpalGateway استفاده کند.

یعنی منطق Checkout به یک پیاده سازی مشخص وابسته شده است.

حالا فرض کنید به جای این کار، Checkout فقط درخواست یک Payment Gateway کند:

const gateway = factory.createGateway();

gateway.pay(500_000);

تفاوت این دو کد شاید در نگاه اول خیلی زیاد به نظر نرسد، اما یک اتفاق مهم افتاده است.

Checkout دیگر نمی داند Object واقعی چگونه ساخته شده است.

حتی لازم نیست بداند این Object از ZarinpalGateway، StripeGateway یا کلاس دیگری ساخته شده.

تنها چیزی که برای Checkout اهمیت دارد این است که Object دریافت شده یک Payment Gateway است و می تواند عملیات پرداخت را انجام دهد.

در نتیجه مسئولیت ها از هم جدا می شوند:

Checkout Service می گوید چه چیزی نیاز دارد.

Factory تصمیم می گیرد چه چیزی ساخته شود.

مثلاً ممکن است یک Factory برای زرین پال داشته باشیم:

class ZarinpalGatewayFactory {
  createGateway(): PaymentGateway {
    return new ZarinpalGateway();
  }
}

و در بخش دیگری از برنامه:

const factory = new ZarinpalGatewayFactory();

const gateway = factory.createGateway();

gateway.pay(500_000);

اگر بعداً بخواهیم از Stripe استفاده کنیم، می توانیم Factory دیگری داشته باشیم که StripeGateway را ایجاد کند، بدون اینکه منطق اصلی پرداخت مجبور باشد جزئیات ساخت آن را بداند.

این ایده اصلی Factory Method است:

کدی که از یک Object استفاده می کند، لازم نیست مسئول تصمیم گیری درباره نحوه ساخت آن Object هم باشد.

البته یک نکته مهم باقی می ماند.

هر تابع یا کلاسی که Object می سازد الزاماً Factory Method Pattern نیست.

مثلاً اگر فقط یک تابع داشته باشیم که با چند if یا switch بین ZarinpalGateway و StripeGateway انتخاب کند، چیزی که ساخته ایم بیشتر به Simple Factory شباهت دارد.

تفاوت Simple Factory و Factory Method یکی از رایج ترین نقاط سردرگمی هنگام یادگیری این Pattern است.

در بخش بعدی این دو را کنار هم قرار می دهیم و با TypeScript می بینیم Factory Method واقعی چه ساختاری دارد و چرا چیزی فراتر از انتقال چند new به یک فایل دیگر است.

نتیجه گیری

اگر بخواهیم Factory Method را خیلی ساده در ذهن نگه داریم، کافی است این سؤال را از خودمان بپرسیم:

آیا این بخش از برنامه واقعاً باید بداند Object موردنیازش دقیقاً از چه کلاسی و چگونه ساخته می شود؟

اگر پاسخ «نه» باشد، احتمالاً جدا کردن مسئولیت ساخت Object می تواند طراحی بهتری ایجاد کند.

در مثال ما، Checkout فقط می خواهد یک پرداخت انجام دهد. برایش مهم نیست پشت صحنه ZarinpalGateway ساخته شده، StripeGateway یا یک Gateway دیگر.

این همان مرزی است که Factory Method تلاش می کند ایجاد کند:

منطق برنامه روی کاری که باید انجام شود تمرکز می کند و جزئیات ساخت Object در جای دیگری مدیریت می شود.

البته این به این معنی نیست که هر جا new دیدیم باید سریع یک Factory بسازیم. برای Objectهای ساده و مشخص، استفاده مستقیم از new کاملاً طبیعی است. Factory Method زمانی ارزش پیدا می کند که نحوه یا نوع Object قابل تغییر باشد و نخواهیم این تصمیم در منطق اصلی برنامه پخش شود.

Factory Method Pattern؛ ساخت آبجکت‌ها را به چه کسی بسپاریم؟

علی صفری

نظرات