💻 آخرین فرصت یادگیری برنامه‌نویسی با آفر ویژه قبل از افزایش قیمت در ۵ آذر ماه (🎁 به همراه یک هدیه ارزشمند )
۰ ثانیه
۰ دقیقه
۰ ساعت
۲ آرمین صادقیان
ریفکتور کردن کدهای جلسه
جامعه پی اچ پی ایجاد شده در ۰۴ تیر ۱۴۰۱

سلام.

توی مثالی که توی این جلسه زده شد متد pay توی هر دو اینترفیس تکرار شده. بهتر نیست این برنامه رو اینجوری Refactor کنیم؟

interface Payable
{
    public function pay();
}
interface Verifiable
{
    public function verify();
}
class OnlinePayment implements Payable, Verifiable
{
    public function pay()
    {
        // TODO: Implement pay() method.
    }
    public function verify()
    {
        // TODO: Implement verify() method.
    }
}
class OfflinePayment implements Payable
{
    public function pay()
    {
        // TODO: Implement pay() method.
    }
}

اصل ISP توی این برنامه رعایت شده ولی اصل LSP رعایت نمیشه چون توی اصل LSP میگیم کلاس‌ها باید بتونن راحت باهم جایگزین بشن ولی اینجوری با جایگزین کردن این کلاس‌ها برنامه به مشکل میخوره چون مثلا کلاس آنلاین پیمنت دوتا متد پیاده میکنه ولی آفلاین پیمنت فقط یدونه متد اینا اگه با هم جابجا بشن برنامه به مشکل نمیخوره؟

دقیقا مثالی هم که توی ویدیو زده شد همینجوریه یک کلاس دو تا متد پیاده میکنه ولی یه کلاس دیگه یک متد

سلام دوست عزیز

ببینید کپی که نوشتید رو میشه در این سناریو پذیرفت اما تصور کنید ما داخل بیزنسمون ۲ مرحله پرداخت دیگه برای offline داریم و یا برعکس در این حالت باید برای هر متد یه interface بنویسیم که برامون مشکل ساز میشه پس بهتره بیایم یه اینترفیس online و offline داشته باشیم

موفق باشید ?

بهترین پاسخ
محمد گازری ۰۵ تیر ۱۴۰۱، ۰۳:۵۰

پیشنهاد من برای عدم تکرار متد pay داخل interface‌ها اینه که یک interface با نام paymentInterface پدر داشته باشیم که دارای متدهای مشترک باشه (مثلا اینجا متد pay)، و Online و Offline بیان extends کنن paymentInterface  رو و متد verify  فقط داخل Online تعریف بشه. به این صورت متدهای مشترک داخل پدر تعریف میشن و متدهای اختصاصی داخل هر interface مخصوص خودش. دلیلش هم اینه که به نظرم هر دو interface آنلاین و آفلاین از یک جنس هستند پس میتونن بچه‌های یک interface پرداخت پدر باشن.

پویا ۰۱ دی ۱۴۰۲، ۰۹:۵۱