اصل چهارم پیاده سازی SOLID با کدهای دارت برای فریم ورک Flutter

Interface Segregation Principle
Interface Segregation Principle

“اصل جداسازی اینترفیس ها “یا (Interface Segregation Principle) یا به طور خلاصه (ISP) ، چهارمین اصل از SOLID است و می گوید که: “کلاینت ها نباید مجبور شوند به اینترفیس هایی وابسته شوند که از آنها استفاده نمی کنند”. به زبانی بسیار ساده تر، باید اینترفیس را طوری طراحی کنیم که وقتی کلاسی از آن استفاده می کند، ملزم نباشد متدی که از آن استفاده نمی کند را پیاده‌سازی ( یا override ) کند.

خیلی خلاصه تر و در یک جمله کوتاه "به چیزهایی که نیاز ندارید وابسته نباشید".


برای اینکه مفهوم را در مثال عملی کاملتر متوجه شویم آن را به دو شیوه صحیح و غلط آن پیاده سازی میکنیم.

۱- مثال زیر ISP را نقض می کند.

بیایید فرض کنیم که یک آژانس مسافرتی وجود دارد که شامل چندین روش برای رزور بلیط هواپیما می باشد. مثلا مشتریان آنلاین، تلفنی و حضوری دارد.

همچنین برای رسیدگی به پرداخت های آنها، درگاه آنلاین برای (مشتریان آنلاین) و پرداخت از درگاه POS را برای (مشتریان حضوری و تلفنی) دارد.

برای شروع یک اینترفیس یا کلاس abstract به نام TravelAgencyInterface ایجاد می کنیم .

abstract class TravelAgencyInterface {

  void acceptWalkInReserveTicket();

  void acceptOnlineReserveTicket ();

  void acceptTelephoneReserveTicket();

  void payOnline();

  void payByPOS();
}

همانطور که مشاهده می کنید ما سه متد برای مشتری حضوری، مشتری تلفنی و مشتری آنلاین داریم. مشتری حضوری و تلفنی با دستگاه POS و مشتری آنلاین با استفاده از درگاه پرداخت آنلاین هزینه بلیط را پرداخت خواهند کرد.

بیایید با ایمپلمنت کردن TravelAgencyInterface برای مشتریان آنلاین کار را شروع کنیم. نام کلاس را OnlineCustomerImpl در نظر می گیریم .

class OnlineCustomerImpl implements TravelAgencyInterface {

    @override
  void acceptWalkInReserveTicket() {
        // Not Applicable
    throw Exception();
  }

  @override
  void acceptOnlineReserveTicket() {
    // Logic for online customer
  }

  @override
  void acceptTelephoneReserveTicket() {
    // Not Applicable
    throw Exception();
  }

    void payOnline(){
      // Logic for online payment
    }

  void payByPOS(){
    // Not Applicable
    throw Exception(); 
  }
}

از آنجایی که OnlineCustomerImpl برای مشتریان آنلاین است، ما باید یک Exception برای متدهایی که برای مشتریان آنلاین نیست اجرا کنیم. در اینجاست که می‌توانیم نقض آشکار اصل جداسازی اینترفیس ها را مشاهده کنیم که علاوه بر آن اصل مسئولیت واحد را نیز زیر پا گذاشته است!

اکنون بیایید این بار با رعایت اصل جداسازی اینترفیس ها ، ایرادات برنامه فوق را برطرف کنیم.

۲- مثال زیر ISP را رعایت می کند.

برای حل مشکل، اقدام به کوچک تر کردن اینترفیس OnlineCustomerImpl کرده و آن را به دو اینترفیس OrderInterface و PaymentInterface تقسیم می کنیم.

abstract class OrderInterface  {
  void reserveOrder();
}

abstract class PaymentInterface {
  void payForOrder();
}

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

class OnlineCustomerImpl implements OrderInterface, PaymentInterface {

  @override
  void reserveOrder() {
    // logic for online reserve
  }

  @override
  void payForOrder() {
    // logic to do online payment
  }
}

class WalkInCustomerImpl implements OrderInterface, PaymentInterface {
  @override
  void reserveOrder() {
    // logic for in-person reserve
  }

  @override
  void payForOrder() {
    // logic to do pos payment
  }
}

class TelephoneCustomerImpl implements OrderInterface, PaymentInterface {
  @override
  void reserveOrder() {
    // logic for telephonic reserve
  }

  @override
  void payForOrder() {
    // logic to do pos payment
  }
}

از مزایایی که اصل جداسازی اینترفیس ها برای ما فراهم کرده میتوانیم به موارد زیر اشاره کنیم :
۱- افزایش خوانایی کد
۲- پیاده سازی آسان تر
۳-نگهداری آسان تر
۴-سازماندهی بهتر کد
۵- نیازی نیست از throw Exception های بیهوده استفاده کنید.

نکته پایانی اینکه، هر دو اصل جداسازی اینترفیس ها و اصل تک مسئولیتی تقریباً یک هدف دارند:
اطمینان از اجزای نرم افزاری کوچک، متمرکز و بسیار منسجم.

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


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

مقدمه ای بر SOLID

توضیح اصل اول : Single Responsibility Principle

توضیح اصل دوم : Open Closed Principle

توضیح اصل سوم : Liskov Substitution Principle

توضیح اصل چهارم : Interface Segregation Principle

توضیح اصل پنجم : Dependency Inversion Principle