فلسفه استفاده از interface ها

در پاسخ به: @mohammadeng3731
توضیحاتش توی این لینک هست میتونی کامل مطالعه کنی

تا جایی که من می دونم برای استفاده در سیستم هایی هست که قراره به صورت چند ریختی کار کنن ولی تاحالا خودم توی پروژه ازش استفاده نکردم ولی تو هسته لاراول تا دلت بخواد ازش استفاده شده.

@mohammadeng3731
سلام و وقت بخیر
چیزی که من تا الان فهمیدم ، برای حالتی هست که بخواهید توی چندین کلاس ، توابعی با اسم یکسان و شاید هم خروجی یکسان داشته باشید ولی با هم متفاوت باشند ،
مثال داخل لینکی که جناب علی قربانی قرار دادن واقعا کامله :
مثلاً توابع مساحت و محیط برای تمامی اشکال هندسی وجود دارن و خروجی همه هم عدده ولی شیوه محاسبه مساحت دایره و مستطیل و دیگر اشکال با هم فرق داره . در نتیجه یه interface داریم شامل دو تابع محیط و مساحت و اشکال هندسی میشن کلاس های متفاوت که اون interface رو به ارث می‌برند
خیلی مبتدی گفتم ولی گویا بود 😅
تجربه دوستان البته بیشتره
موفق و سلامت باشید
یا حق

یکی از مهمترین تاپیک هایی که در برنامه نویسی شئ-گرا مطرح هست.. همین Interface هست.

همیشه کلاس های که ما در کد هامون استفاده میکنیم Concrete نیستند..
اکثر مواقع برای نوشتن کدهای تمیز و قابل توسعه باید از انتزاع (Abstraction) استفاده کنیم
این انتزاع میتونه به این شکل باشه:

• ما یه سری قوانین (متدهای اینترفیس) داریم
• که یک سری از کلاس های ما باید به اون قوانین پایبند باشند.. (با implementation)
• حالا اینترفیس رو مثل یک قرارداد در نظر بگیر..
• که کلاس هایی که اون رو implement میکنند
• در واقع دارند از اون قرار داد تبعیت میکنند.

مثلال اشکال هندسی رو استفاده میکنم:
فرض کنیم شما باید اطلاعات یک سری اشکال هندسی رو محاسبه کنی (محیط و مساحت و ...)
پس هر شکل رو تبدیل به یک کلاس میکنی و لاجیک رو درش قرار میدی
لاجیک این کلاس ها با هم فرق میکنه اما عملکرد های مشترک دارند (مثلا هر ۲ باید بتونند محیط رو محاسبه کنند)
و این عملکردهای مشترک، در واقع همون قانونی هست که ما در اینترفیس تعریف می‌کنیم.

اینترفیس زیر رو در نظر بگیر:

interface Shape {
    public function area();
}

این اینترفیس کلاس هایی رو که ازش تبعیت میکنند رو مجبور میکنه تا هر کدوم یک متد area (برای محاسبه محیط) داشته باشند.. وگرنه با خطا روبرو میشیم.
پس ما یک قانون کلی در اپلیکیشن به وجود اوردیم => هر Shape ی که در سیستم ما تعریف میشه، باید روشی برای محاسبه محیط رو در خودش داشته باشه

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

class Circle implements Shape  {
    public function area() {
        return $this->radius * 3.14;
    }
}

class Square implements Shape {
    public function area() {
        return $this->side * $side;
    }
}

یکی از فواید این کار الگوی طراحی استراتژی و پلی مورفیسم (Polymorphism) هست.

• خانواده ای از الگوریتم ها رو تعریف می‌کنیم
• الزام تبعیت از قرارداد (اینترفیس) رو بوجود بیاریم
• وابستگی تزریق‌شده رو٬ (که از خانواده الگوریتم‌هاست) با اینترفیس عوض می‌کنیم

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

• بدون تغییر دادن کد ها بتونیم، اون ها رو توسعه بدیم
• قانون دوم از قوانین SOLID به نام Open–closed Principle هم رعایت میشه

در مورد این الگو من مقاله ای نوشتم که میتونی مطالعه کنی:
الگوی طراحی استراتژی (Strategy) در زبان PHP

من به صورت تیمی کار نکردم ولی به نظرم واسه کاره تیمی هم این سبک مناسب تر هستش
ابتدا بیاییم متدهای مورد نیاز رو تو interface ها مشخص کنیم و سپس به سایر افراد گروه بگیم تا این متدها رو در کلاسهای مختلف پیاده سازی کنند

@ebibombas1988
در واقع بهتره گفت Business Logic هست که این متد ها (یا بند های قرارداد) رو مشخص میکنه.
پس بر اساس منطق کارکرد اپلیکیشن، قوانین خاصی در معماری تعریف میشه..

وقتی شما چنین کدی رو به برنامه‌نویس دیگه میدی .. و اون شخص به محضی ببینه یه Interface داخل کد شما هست.. متوجه میشه که کلاس های که ازش پیروی میکنند، همه یک سری لاجیک مشخص رو در خودشون دارند.
پس اگر خواست نوع عملکرد جدیدی هم به سیستم اضافه کنه، کار سختی در پیش نداره » چون چنین کدی قابل توسعه هست.