الگوهای طراحی به زبان ساده - Factory Method

اما این پایان کار نیست. بجای اینکه آبجکت‌ها رو به صورت مستقیم توی متد makeVehicle بسازیم، می‌تونیم برای هر نوع آبجکت، یک زیرکلاس اختصاصی از کلاس Delivery بسازیم تا با رونوشت (Override) کردن متد فکتوری، کار ساختن آبجکت واگذار بشه به زیر کلاس‌ها.

ابتدا کلاس اصلی یعنی Delivery رو آماده انجام این کار کنیم:

abstract class Delivery {
  public abstract makeVehicle();

  public handle() {
    const vehicle = this.makeVehicle();
    vehicle.move();
  }
}

متد فکتوری یعنی makeVehicle رو از نوع Abstract کردیم تا زیرکلاس‌ها مجبور باشن اون رو پیاده‌سازی کنن. حالا برای هر نوع آبجکت (روش ارسال)، یک زیر کلاس می‌سازیم:

class BikeDelivery extends Delivery {
  public makeVehicle() {
    const bike = new Bike();
    bike.setMode('eco');

    return bike;
  }
}

class CarDelivery extends Delivery {
  public makeVehicle() {
    const car = new Car();
    car.setColor('green');

    return car;
  }
}

همونطور که می‌بینیم، کار ساختن آبجکت‌ها رو واگذار کردیم به زیر کلاس‌ها و اینطوری می‌تونیم بی‌نهایت روش ارسال داشته باشیم بدون اینکه کدهامون رو دستکاری کنیم.

حالا با توجه به روش ارسال مدنظرمون، یکی از این زیرکلاس‌ها رو پیاده‌سازی و استفاده می‌کنیم:

const byCar = new CarDelivery();
byCar.handle();

// ...

const byBike = new BikeDelivery();
byBike.handle();

خب این بود الگوی فکتوری متد. متد makeVehicle مسئول ساختن آبجکت‌ها شد و متد handle بدون اطلاع از اینکه آبجکت‌ها به چه صورت ساخته میشن، کار خودش رو انجام میده.

اما این کد هنوز ۱۰۰٪ قابل اعتماد نیست! چرا؟ کلاس‌های Bike و Car از هیچ اینترفیسی تبعیت نمی‌کنن. متد handle رو در نظر بگیرید:

public handle() {
  const vehicle = this.makeVehicle();
  vehicle.move();
}

از کجا می‌دونیم آبجکتِ ساخته‌شده متدی به اسم move داره؟ مطمئن نیستیم مگر اینکه که یک اینترفیس وجود داشته باشه. خب ابتدا باید برای کلاس‌های Car و Bike یک اینترفیس بسازیم:

interface Vehicle {
  setMode(mode);
  move();
}

class Bike implements Vehicle {
  setMode(mode) { /* */}

  move() { /* */ };
}

class Car implements Vehicle {
  setMode(mode) { /* */ }

  move() { /* */ }

  setColor(color) { /* */ }
}

چون متد فکتوری قراره آبجکت‌هامون (Bike یا Car) رو بسازه و تحویل بده، نوع خروجی اون رو برابر با این اینترفیس قرار می‌دیم (خط ۲):

abstract class Delivery {
  public abstract makeVehicle(): Vehicle;

  public handle() {
    const vehicle = this.makeVehicle();
    vehicle.move();
  }
}

خب اینجا دیگه کد ما تکمیل و قابل استفاده شد 👌 کد کامل این مثال رو از گیت‌هاب ببینین. Star هم بزنین ⭐😉

چه زمانی از الگوی Factory Method استفاده کنیم؟

از این الگو زمانی استفاده می‌کنیم که آبجکت‌های متنوعی وجود داره و تا قبل از اجرای برنامه نمی‌دونیم چه نوع آبجکتی و به چه صورتی قراره استفاده بشه. (Bike یا Car؟) همچنین می‌خوایم راهی وجود داشته باشه که بتونیم بی‌نهایت نوع آبجکت داشته باشیم که هر کدوم نحوه ساخت متفاوتی دارن.

مزایای الگوی Factory Method

با جدا کردن قسمت‌های کد (به قول معروف Decoupling) تونستیم کدهایی تمیزتر، خواناتر و با قابلیت توسعه و نگهداری بالاتر بسازیم.

همچنین ۳ اصل از اصول پنجگانه SOLID رو پیاده‌سازی کردیم:

۱. با انتقال دادن مسئولیت ساختن آبجکت‌ها به متد فکتوری، کاری کردیم که متد handle فقط مسئول انجام یک وظیفه باشه (اصل Single Responsibility)

۲. تونستیم کاری کنیم که بتونیم بی‌نهایت نوع بسازیم بدون اینکه کدهامون رو دستکاری کنیم (اصل Open Closed)

۳. تا قبل از پیاده‌سازی این الگو، کلاس Delivery وابسته به کلاس Bike یا Car بود. اما بعد از اعمال این الگو، این وابستگی از بین رفت (اصل Dependency Inversion)

برای آشنایی با اصول SOLID می‌تونید مجموعه پست‌های زیر رو بخونید:

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

منابعی که برای این قسمت استفاده کردم: