در مقاله قبل با Factory Method Pattern آشنا شدیم و دیدیم که گاهی بهتر است کدی که از یک Object استفاده می کند، مسئول ساخت آن Object نباشد.

اما حالا یک مرحله جلوتر برویم.

اگر مسئله ما فقط ساخت یک Object نباشد چه؟

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

اینجاست که به یکی دیگر از اعضای خانواده Creational Patterns می رسیم:

Abstract Factory Pattern

مثل همیشه، قبل از اینکه سراغ تعریف Pattern برویم، اول مسئله را بررسی می کنیم.

مسئله؛ وقتی یک Object کافی نیست

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

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

برای کار با این درگاه، بخش پرداخت ما چند عملیات مختلف دارد:

Payment Service (سرویس پرداخت)
Verify Service (سرویس تأیید پرداخت)
Refund Service (سرویس بازپرداخت)

برای ساده نگه داشتن مثال، فرض می کنیم برای هرکدام یک کلاس جداگانه داریم:

class BehpardakhtPayment {
  pay(amount: number): void {
    console.log(`Pay ${amount} using Behpardakht`);
  }
}

class BehpardakhtVerify {
  verify(transactionId: string): void {
    console.log(`Verify ${transactionId} using Behpardakht`);
  }
}

class BehpardakhtRefund {
  refund(transactionId: string): void {
    console.log(`Refund ${transactionId} using Behpardakht`);
  }
}

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

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

بنابراین برای IDPay هم پیاده سازی های مربوط به خودش را خواهیم داشت:

IDPayPayment
IDPayVerify
IDPayRefund

حالا اگر از بالا به ساختار سیستم نگاه کنیم، دو مجموعه متفاوت داریم:

Behpardakht
├── Payment
├── Verify
└── Refund

IDPay
├── Payment
├── Verify
└── Refund

اینجا دیگر فقط درباره انتخاب یک کلاس صحبت نمی کنیم.

ما چند Object مختلف داریم که به یکدیگر مرتبط هستند.

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

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

برای شروع پرداخت باید از:

BehpardakhtPayment

استفاده کنیم.

بعد از بازگشت کاربر از درگاه، تأیید Transaction هم باید توسط:

BehpardakhtVerify

انجام شود.

اگر نیاز به بازپرداخت داشته باشیم نیز باید سراغ:

BehpardakhtRefund

برویم.

یعنی این سه Object مستقل از یکدیگر نیستند.

آن ها اعضای یک خانواده هستند.

برای IDPay نیز دقیقاً همین وضعیت وجود دارد:

IDPayPayment
IDPayVerify
IDPayRefund

اگر Provider انتخاب شده IDPay باشد، باید اعضای خانواده IDPay را کنار هم استفاده کنیم.

اگر این هماهنگی را کنترل نکنیم چه می شود؟

فرض کنید بخش های مختلف برنامه خودشان تصمیم بگیرند چه Objectی بسازند.

Checkout Service (سرویس ثبت و نهایی سازی خرید) می نویسد:

const payment = new BehpardakhtPayment();

پرداخت انجام می شود.

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

const verify = new IDPayVerify();

حالا Transaction از طریق به پرداخت ملت ایجاد شده، اما برنامه تلاش می کند آن را با IDPay تأیید کند.

هر دو کلاس به تنهایی کاملاً معتبر هستند.

BehpardakhtPayment مشکلی ندارد.

IDPayVerify هم مشکلی ندارد.

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

بنابراین چیزی که باید کنترل کنیم فقط نوع Object نیست.

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

Product Family چیست؟

اینجا با یکی از مفاهیم اصلی Abstract Factory روبه رو می شویم:

Product Family

Product Family یعنی مجموعه ای از Objectهای مرتبط که برای کار کردن در یک Context مشخص طراحی شده اند.

در مثال ما:

Behpardakht Family
├── Payment
├── Verify
└── Refund

یک Product Family است.

و:

IDPay Family
├── Payment
├── Verify
└── Refund

یک Product Family دیگر.

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

پس هدف ما فقط این نیست که بتوانیم Paymentهای مختلف بسازیم.

می خواهیم بتوانیم کل خانواده پرداخت را با هم انتخاب کنیم.

❌ راه حل ساده؛ استفاده از شرط

اولین راه حل احتمالاً استفاده از if یا switch است.

مثلاً:

function createPaymentServices(provider: string) {
  if (provider === 'behpardakht') {
    return {
      payment: new BehpardakhtPayment(),
      verify: new BehpardakhtVerify(),
      refund: new BehpardakhtRefund(),
    };
  }

  if (provider === 'idpay') {
    return {
      payment: new IDPayPayment(),
      verify: new IDPayVerify(),
      refund: new IDPayRefund(),
    };
  }

  throw new Error('Unsupported payment provider');
}

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

حتی برای پروژه ای کوچک ممکن است کاملاً کافی باشد.

اما مسئله زمانی جدی تر می شود که پروژه رشد کند.

فرض کنید بعداً Providerهای دیگری اضافه شوند.

یا هر Provider علاوه بر Payment و Verify و Refund، سرویس های دیگری مثل Settlement یا Inquiry هم داشته باشد.

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

مهم تر از آن، منطق اصلی برنامه باید بداند:

اگر Provider به پرداخت ملت بود، دقیقاً چه کلاس هایی باید ساخته شوند؟

در حالی که این تصمیم لزوماً مسئولیت Checkout، Order یا Invoice نیست.

اگر یک Factory مسئول کل خانواده باشد چه؟

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

به جای اینکه Checkout تصمیم بگیرد:

BehpardakhtPayment بسازم یا IDPayPayment؟

به آن می گوییم:

تو فقط Payment می خواهی. اینکه کدام پیاده سازی ساخته شود، مسئولیت تو نیست.

همین موضوع برای Verify و Refund نیز وجود دارد.

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

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

interface Verify {
  verify(transactionId: string): void;
}

interface Refund {
  refund(transactionId: string): void;
}

حالا پیاده سازی های به پرداخت ملت این Contractها را پیاده می کنند:

class BehpardakhtPayment implements Payment {
  pay(amount: number): void {
    console.log(`Pay ${amount} using Behpardakht`);
  }
}

class BehpardakhtVerify implements Verify {
  verify(transactionId: string): void {
    console.log(`Verify ${transactionId} using Behpardakht`);
  }
}

class BehpardakhtRefund implements Refund {
  refund(transactionId: string): void {
    console.log(`Refund ${transactionId} using Behpardakht`);
  }
}

و IDPay هم پیاده سازی خودش را دارد:

class IDPayPayment implements Payment {
  pay(amount: number): void {
    console.log(`Pay ${amount} using IDPay`);
  }
}

class IDPayVerify implements Verify {
  verify(transactionId: string): void {
    console.log(`Verify ${transactionId} using IDPay`);
  }
}

class IDPayRefund implements Refund {
  refund(transactionId: string): void {
    console.log(`Refund ${transactionId} using IDPay`);
  }
}

تا اینجا فقط یک Contract مشترک بین اعضای مشابه خانواده ها ایجاد کرده ایم.

هنوز Abstract Factory نداریم.

ساخت Factory مشترک

حالا به یک Contract دیگر نیاز داریم.

Contractی که مشخص کند هر Payment Provider باید بتواند خانواده کامل خودش را بسازد.

interface PaymentFactory {
  createPayment(): Payment;
  createVerify(): Verify;
  createRefund(): Refund;
}

این Interface نمی داند قرار است به پرداخت ملت استفاده شود یا IDPay.

فقط می گوید:

هر Factory پرداخت باید بتواند:

Payment بسازد.
Verify بسازد.
Refund بسازد.

حالا برای هر خانواده یک Factory ایجاد می کنیم.

Factory مربوط به به پرداخت ملت

class BehpardakhtFactory implements PaymentFactory {
  createPayment(): Payment {
    return new BehpardakhtPayment();
  }

  createVerify(): Verify {
    return new BehpardakhtVerify();
  }

  createRefund(): Refund {
    return new BehpardakhtRefund();
  }
}

این Factory فقط اعضای خانواده Behpardakht را تولید می کند.

اگر از آن Payment بخواهیم:

factory.createPayment();

BehpardakhtPayment دریافت می کنیم.

اگر Verify بخواهیم:

factory.createVerify();

BehpardakhtVerify دریافت می کنیم.

بنابراین اعضای خانواده با یکدیگر هماهنگ باقی می مانند.

Factory مربوط به IDPay

برای IDPay هم همین ساختار را داریم:

class IDPayFactory implements PaymentFactory {
  createPayment(): Payment {
    return new IDPayPayment();
  }

  createVerify(): Verify {
    return new IDPayVerify();
  }

  createRefund(): Refund {
    return new IDPayRefund();
  }
}

حالا انتخاب Factory، خانواده ای که قرار است استفاده شود را مشخص می کند.

استفاده از Abstract Factory در برنامه

فرض کنید یک بخش از برنامه مسئول انجام فرآیند پرداخت است.

این بخش به جای وابستگی مستقیم به به پرداخت ملت یا IDPay، فقط PaymentFactory را می شناسد.

function processPayment(factory: PaymentFactory): void {
  const payment = factory.createPayment();
  const verify = factory.createVerify();

  payment.pay(500_000);
  verify.verify('transaction-123');
}

نکته مهم اینجاست که processPayment هیچ اطلاعی درباره Provider واقعی ندارد.

در این تابع خبری از:

new BehpardakhtPayment();

یا:

new IDPayPayment();

نیست.

اگر بخواهیم از به پرداخت ملت استفاده کنیم:

const factory = new BehpardakhtFactory();

processPayment(factory);

و اگر بخواهیم IDPay را استفاده کنیم:

const factory = new IDPayFactory();

processPayment(factory);

خود processPayment هیچ تغییری نکرد.

فقط Factory تغییر کرده است.

و با تغییر Factory، کل خانواده Objectهای قابل ساخت تغییر کرده است.

این هسته اصلی Abstract Factory است.

Abstract Factory Pattern چیست؟

حالا می توانیم تعریف Pattern را خیلی ساده تر بیان کنیم.

Abstract Factory یک Creational Pattern است که مسئولیت ساخت مجموعه ای از Objectهای مرتبط را به یک Factory می سپارد تا Objectهای ساخته شده متعلق به یک خانواده و با یکدیگر سازگار باشند.

در مثال ما:

PaymentFactory

Abstract Factory است.

و:

BehpardakhtFactory
IDPayFactory

Concrete Factoryهای ما هستند.

از طرف دیگر:

Payment
Verify
Refund

انواع Productهای ما هستند.

و پیاده سازی هایی مثل:

BehpardakhtPayment
BehpardakhtVerify
BehpardakhtRefund

یک Product Family را تشکیل می دهند.

تفاوت Factory Method و Abstract Factory چیست؟

اینجا احتمالاً مهم ترین سؤال مقاله مطرح می شود.

چون در مقاله قبلی Factory Method را بررسی کردیم، ممکن است این دو Pattern در نگاه اول بسیار شبیه به هم به نظر برسند.

هر دو درباره ساخت Object صحبت می کنند.

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

اما مسئله ای که حل می کنند یکسان نیست.

در Factory Method معمولاً سؤال ما این است:

چه Objectی باید ساخته شود؟

مثلاً می خواهیم یک Payment Gateway داشته باشیم و تصمیم ساخت پیاده سازی مناسب را از Client جدا کنیم.

اما در Abstract Factory سؤال کمی متفاوت است:

کدام خانواده از Objectهای مرتبط باید ساخته شود؟

در مثال فعلی فقط Payment نداریم.

ما:

Payment
Verify
Refund

داریم و می خواهیم هر سه متعلق به یک Provider باشند.

پس اگر بخواهیم تفاوت را خیلی ساده در ذهن نگه داریم:

Factory Method: چه Objectی بسازم؟

Abstract Factory: کدام خانواده از Objectهای مرتبط را بسازم؟

یک مثال ساده برای تشخیص تفاوت

فرض کنید فقط این ساختار را داریم:

Payment
   │
   ├── BehpardakhtPayment
   └── IDPayPayment

اگر فقط مسئله انتخاب نحوه ساخت Payment باشد، احتمالاً Factory Method برای مسئله ما کافی است.

اما اگر ساختار این باشد:

                 Payment Provider
                       │
          ┌────────────┴────────────┐
          │                         │
    Behpardakht                   IDPay
          │                         │
     ┌────┼────┐               ┌────┼────┐
     │    │    │               │    │    │
 Payment Verify Refund      Payment Verify Refund

حالا با چند Product مرتبط روبه رو هستیم.

در چنین شرایطی Abstract Factory معنی بیشتری پیدا می کند.

چطور بفهمیم با Product Family روبه رو هستیم؟

یک نشانه ساده وجود دارد.

فرض کنید چنین ساختاری دارید:

A1    A2    A3
B1    B2    B3

اگر:

A1

باید با:

A2
A3

استفاده شود و ترکیب آن با:

B2
B3

منطقی نباشد، احتمالاً با Product Family روبه رو هستید.

در مثال ما:

BehpardakhtPayment
BehpardakhtVerify
BehpardakhtRefund

یک خانواده هستند.

و:

IDPayPayment
IDPayVerify
IDPayRefund

خانواده دیگری هستند.

همین مفهوم یکی از مهم ترین نشانه ها برای تشخیص Abstract Factory است.

مزایای Abstract Factory

یکی از مهم ترین مزایای Abstract Factory این است که سازگاری بین Objectهای یک خانواده را حفظ می کند.

وقتی BehpardakhtFactory انتخاب شده، تمام Objectهایی که از آن دریافت می کنیم متعلق به همان Provider هستند.

مزیت دیگر، کاهش وابستگی Client به کلاس های Concrete است.

کد اصلی برنامه لازم نیست بداند:

BehpardakhtPayment
IDPayPayment
BehpardakhtVerify
IDPayVerify

چگونه ساخته می شوند.

Client فقط Contractهای عمومی مثل Payment، Verify و Refund را می شناسد.

این موضوع تعویض یک خانواده کامل را نیز ساده تر می کند.

به جای تغییر چندین بخش برنامه، می توان Factory مورد استفاده را تغییر داد.

معایب Abstract Factory

این Pattern در کنار مزایای خودش می تواند پیچیدگی زیادی هم ایجاد کند.

برای یک سیستم ساده با یک Payment Provider، ساختن:

چند Interface
چند Concrete Product
Abstract Factory
Concrete Factory

احتمالاً بیش از حد نیاز است.

در چنین شرایطی یک طراحی ساده تر انتخاب بهتری خواهد بود.

مشکل دیگر زمانی ظاهر می شود که بخواهیم نوع Product جدیدی به تمام خانواده ها اضافه کنیم.

فرض کنید علاوه بر Payment، Verify و Refund، حالا به Inquiry هم نیاز داریم.

باید Contract اصلی را تغییر دهیم:

interface PaymentFactory {
  createPayment(): Payment;
  createVerify(): Verify;
  createRefund(): Refund;
  createInquiry(): Inquiry;
}

حالا تمام Factoryهای موجود نیز باید createInquiry() را پیاده سازی کنند.

بنابراین Abstract Factory برای اضافه کردن خانواده جدید مناسب است، اما اضافه کردن نوع Product جدید می تواند تغییرات بیشتری ایجاد کند.

چه زمانی از Abstract Factory استفاده کنیم؟

Abstract Factory زمانی می تواند انتخاب خوبی باشد که:

چند خانواده متفاوت از Objectها داشته باشیم.
هر خانواده شامل چند Product مرتبط باشد.
اعضای یک خانواده باید با یکدیگر سازگار باقی بمانند.
بخواهیم بتوانیم یک خانواده کامل را بدون تغییر منطق اصلی برنامه جایگزین کنیم.
نخواهیم Client به کلاس های Concrete وابسته باشد.

چه زمانی از Abstract Factory استفاده نکنیم؟

اگر فقط یک Product داریم، احتمالاً Factory Method یا حتی ساخت مستقیم Object کافی است.

اگر فقط یک خانواده داریم و قرار نیست خانواده دیگری اضافه شود، Abstract Factory ممکن است فقط کد را پیچیده تر کند.

همچنین اگر Objectهای شما ارتباط خاصی با یکدیگر ندارند، قرار دادن آن ها داخل یک Factory مشترک صرفاً به دلیل شباهت ظاهری، طراحی مناسبی نیست.

Pattern زمانی ارزش دارد که مسئله واقعی وجود داشته باشد.

نه زمانی که فقط می خواهیم Patternی در پروژه استفاده کرده باشیم.

جمع بندی

Abstract Factory در نگاه اول ممکن است یکی از Patternهای پیچیده خانواده Creational به نظر برسد.

اما اگر مفهوم Product Family را درک کنیم، ایده اصلی آن بسیار ساده تر می شود.

فرض کنید چند مجموعه از Objectهای مرتبط داریم:

Behpardakht
├── Payment
├── Verify
└── Refund

IDPay
├── Payment
├── Verify
└── Refund

اگر انتخاب Behpardakht به این معنی باشد که تمام Objectهای مرتبط نیز باید از خانواده Behpardakht باشند، Abstract Factory می تواند مسئول ساخت این خانواده باشد.

در نتیجه Client لازم نیست بداند هر Object دقیقاً از چه کلاسی ساخته می شود.

فقط Factory مناسب را دریافت می کند و از Productهای آن استفاده می کند.

اگر بخواهیم این Pattern را با یک سؤال به خاطر بسپاریم، کافی است هنگام طراحی از خودمان بپرسیم:

آیا چند نوع Object مرتبط دارم که باید بتوانم خانواده کامل آن ها را با هم تغییر دهم؟

اگر پاسخ مثبت باشد، احتمالاً ارزش دارد Abstract Factory را به عنوان یکی از گزینه های طراحی بررسی کنیم.

در مقاله بعدی از خانواده Creational Patterns سراغ Builder Pattern می رویم و بررسی می کنیم وقتی ساخت یک Object مراحل و تنظیمات زیادی دارد، چطور می توانیم بدون Constructorهای شلوغ و پیچیده آن را مرحله به مرحله بسازیم.

Abstract Factory Pattern؛ وقتی آبجکت‌ها باید با هم سازگار باشند

علی صفری

نظرات