قبلا در مورد کلاسهای abstract در PHP مطلبی نوشتم ، کلاسهای انتزاعی یا abstract کلاسهایی هستند که قابل نمونه گیری نیستند و میتونیم درون کلاسهای انتزاعی متد هایی بنویسیم و در کلاسهایی که از اون مشتق شدن ازش استفاده کنیم. اینترفیس ها دقیقا مثل کلاسهای انتزاعی هستند ، با این تفاوت که در اینترفیس ها هیچ متدی نمیتونه دارای بدنه باشه. اولش خیلی عجیب به نظر میرسه… وقتی متدها بدنه نداشته باشن ، به چه دردی میخودن؟

به خاطر داشته باشید که شما با تعریف یک متد در کلاس abstract نویسنده کلاسهای دیگه (که از این کلاس مشتق شدن) رو وادار نمیکردید که متدهای کلاس پدر رو بازنویسی کنه. ولی در اینترفیس ها اینطور هست، یعنی هر کلاسی که یک اینرفیس رو implement کنه ، باید تمام متدهای کلاس پدر رو بازنویسی کنه.

مثلا شما میخواید کلاسی بسازید که یک تگ html رو رندر کنه و برای این کار نیاز هست که به تگ ، id و class داده بشه. شما میاید یه اینترفیس میسازید و درون اون دو تابع setID  و setClass  رو مینویسید. از اون به بعد هر کسی که کلاس خودش رو از اینترفیس شما مشتق کرد مجبوره که دو تا تابع رو بنویسه و این از خطای برنامه جلوگیری میکنه. شاید در پروژه های کوچیک زیاد به درد نخوره ، ولی پروژه هایی که تعداد زیادی توسعه دهنده روشون کار میکنند ، برای پیاده سازی design pattern ها در اکثر اوقات باید از اینترفیس ها استفاده کنن.

نحوه ی تعریف interface ها در PHP

برای تعریف اینترفیس ها از کلمه کلیدی interface استفاده میکنیم :

interface abc
{
    public function xyz($b);
}

در مثال بالا کلاسها رو مجبور میکنیم که متد xyz رو بنویسن. برای ارث بردن یا به اصطلاح پیاده کردن یک اینترفیس از کلمه کلیدی implements استفاده میکنیم:

class test implements abc
{
   public function xyz($b)
   {
       // The body of your function...
   }
}

نکته قابل توجه اینه که تمام متد ها و پراپرتی هایی که درون یک اینترفیس تعریف میشن باید بصورت عمومی یا public  تعریف بشن ، در غیر اینصورت با اررور مواجه میشیم.

یک نکته دیگه اینکه یک کلاس میتونه بیش از یک اینترفیس رو implement کنه و همچنین یک اینترفیس میتونه از چند اینترفیس دیگه مشتق بشه.

نوشتن کدهای Open-Closed با استفاده از اینترفیس ها

ما در مفاهیم SOLID همیشه تشویق میشیم که کدهامون رو open-closed بنویسیم. ینی کدهامون برای تغییر بسته باشن و جوری کد بزنیم که کلاسها رو هی نیایم دستکاری کنیم همینطور باید کد رو جوری بنویسیم که به راحتی extendable باشه. دلیل این هم شاید برمیگرده به اینکه ریفکتور کردن کدهای اینجوری سخته و باعث بروز مشکلات میشه. من در ادامه یه مثال میارم و روی اون توضیح میدم:

<?php

interface DriverContract
{
    public function connect();
    public function run();
    public function get();
}


class MySQL implements DriverContract
{
    public function connect()
    {
        echo "Connecting to MySQL...\n";
    }
    public function run()
    {
        echo "Running MySQL...\n";
    }
    public function get()
    {
        echo "Getting MySQL...\n";
    }
}

class MongoDB implements DriverContract
{
    public function connect()
    {
        echo "Connecting to MongoDB...\n";
    }
    public function run()
    {
        echo "Running MongoDB...\n";
    }
    public function get()
    {
        echo "Getting MongoDB...\n";
    }
}


function consume(DriverContract $driver)
{
    $driver->connect();
    $driver->run();
    $driver->get();
}

consume(new MySQL());

یه راه ابتدای برای نوشتن این کد اینه که بگیم اگه درایور فلان بود اینجوری کانکت شو و اگه اونیکی بود اونجوری! ولی مشکلی که پیش میاد هر بار که درایور اضافه میشه من باید بیام ایف هام رو دستکاری کنم. با این مدل کد نوشتن من انتخاب درایور رو به کانسومر واگذار کردم و در واقع پیچیدگی کد رو بردم به لایه های بالاتر و همینطور در صورت نیاز به اضافه کردن درایور دیگر، به راحتی فقط کلاسش رو عوض میکنیم و نمیریم کد قبلی رو دستکاری کنیم. در واقع ما با استفاده از یک اینترفیس اون پشت رو از دید کاربر معمولی قایم کردیم و کاربر میدونه که یه درایور رو بگیره و استفاده کنه. مثلا در فریمورک لاراول ما وقتی model binding انجام میدیم مهم نیس که اون مدل با چی ساخته شده! مهم اینه که فانکشن هایی که هر مدل میخواد رو ما داخلش داریم و اینجوریه که دیتابیس رو عوض میکنیم هیچ مشکلی پیش نمیاد. پس کد برای گسترش باز نگه داشته شده و هر چنتا درایور بخوایم میتونیم اضافه کنیم ولی برای تغییر کلوزد هست و کدهای قبلی دستکاری نمیشن.

کدهای Testable با کمک interface ها

اگه با مفاهیم تست نویسی و بخصوص mocking آشنا نیستید شاید این بخش یه خورده گنگ باشه واستون. ولی به هر حال در کد بالا میتونستیم بجای inject کردن اینترفیس مستقیما یک کلاس رو اینجکت کنیم و در ظاهر خیلی اتفاق بدی نمیفتاد. ولی مشکل اصلی زمانی پیش میاد که شما میخواید بدون تغییر در کد یا گرفتن ورودی اضافه کدتون رو تست کنید. اونجا برای تست تابع consume باید حتما ورودی رو از نوع مثلا MySQL میدادید که در این صورت نمیشد یه کلاس فیک برای تست نوشت ولی الان خیلی راحت میتونیم هر نمونه ای که اینترفیس رو پیاده کرده رو به عنوان ورودی به تابع بدیم و اون رو تست کنیم.

در پایان من فرصت نکردم متن رو ریویو کنم اگه مشکلی بود ببخشید و توی کامنت ها بگید که اصلاح کنم 🙂