اگر با برنامه‌نویسی شیءگرا آشنا باشید، احتمالاً در مورد اصول SOLID شنیده‌اید.

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

مقالات زیادی درباره SOLID در اینترنت وجود دارد اما بدون اغراق، من کمتر نمونه‌هایی همراه با تصویر دیده‌ام. این موضوع یادگیری را برای افرادی مثل من که یادگیری بصری را ترجیح می‌دهند سخت‌تر می‌کند.

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

می‌بینید، بعضی از این اصول ممکن است شبیه به هم به نظر برسند، اما هدف یکسانی ندارند. ممکن است قانون یکی را رعایت کنیم و دیگری را نقض، حتی اگر مشابه باشند.

برای ساده‌تر شدن موضوع، من در این مقاله از کلمه «کلاس» استفاده خواهم کرد، اما توجه داشته باشید که این اصول می‌توانند به تابع (Function)، متد (Method) یا ماژول (Module) نیز اعمال شوند.

توجه

برخی نظرات درباره اینکه اصل Open-Closed ممکن است در این مقاله، با اصل تک‌مسئولیتی (Single Responsibility Principle) در تضاد باشد دریافت کردم. لطفاً توجه کنید که هدف این مقاله این است که هر یک از این اصول را به صورت مستقل توضیح دهد.

همچنین «مسئولیت‌ها» یا «نقش‌ها» با «عملیات» متفاوت هستند. در SRP گفتم «من نقاش هستم»، اما در Open-Closed گفتم «من می‌توانم نقاشی کنم».

توجه به این امر مهم است چون برای انجام یک مسئولیت (نقش) معمولاً چندین عملیات قابل انجام است. کلاس باید یک مسئولیت داشته باشد (SRP) ولی کارکردها یا عملکردهای آن که آن مسئولیت را فراهم می‌آورند، باید قابل توسعه باشند (OCP).

پس بیایید شروع کنیم!

---

اصول SOLID

S — Single Responsibility Principle (اصل تک‌مسئولیتی)

یک کلاس باید تنها یک مسئولیت داشته باشد

اگر یک کلاس چند مسئولیت داشته باشد، احتمال بروز باگ افزایش می‌یابد چون تغییر روی یک مسئولیت ممکن است بدون اطلاع، سایر مسئولیت‌ها را نیز تحت تأثیر قرار دهد.

هدف

این اصل تلاش می‌کند رفتارها را جدا کند تا اگر باگی ناشی از تغییر شما رخ داد، روی رفتارهای نامرتبط تأثیر نگذارد.

---

O — Open-Closed Principle (اصل باز-بسته)

کلاس‌ها باید برای توسعه (افزودن قابلیت) باز، اما برای تغییر بسته باشند

تغییر رفتار فعلی یک کلاس، تمام سیستم‌هایی که از آن کلاس استفاده می‌کنند را تحت تاثیر قرار می‌دهد.

اگر بخواهید کلاس قابلیت‌های بیشتری داشته باشد، بهتر است اضافه کنید به آنچه که قبلاً هست، نه اینکه آن را تغییر دهید.

هدف

این اصل به دنبال افزودن رفتارهای جدید به کلاس است بدون تغییر رفتار موجود تا از بروز باگ در بخش‌های مختلف جلوگیری شود.

---

L — Liskov Substitution Principle (اصل جانشینی لیسکوف)

اگر S زیرنوع (subtype) نوع T باشد، آنگاه می‌توان اشیاء از نوع T را در برنامه با اشیاء نوع S جایگزین کرد بدون اینکه خواص مطلوب برنامه تغییر کند.

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

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

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

در تصویر، کلاس والد قهوه می‌دهد (هر نوع قهوه‌ای). کلاس فرزند می‌تواند کاپوچینو بدهد چون نوع خاصی از قهوه است اما دادن آب قابل قبول نیست.

اگر کلاس فرزند این شرایط را نداشته باشد، یعنی کلاس فرزند کاملاً تغییر کرده و این اصل نقض شده است.

هدف

این اصل به دنبال تضمین سازگاری است تا بتوان به شکل یکسان از کلاس والد یا فرزند بدون خطا استفاده کرد.

---

I — Interface Segregation Principle (اصل تقسیم‌بندی رابط)

مشتریان نباید مجبور باشند به متدهایی وابسته باشند که استفاده نمی‌کنند.

وقتی یک کلاس مجبور است عملیاتی انجام دهد که برایش کاربردی ندارد، باعث هدر رفت منابع و ایجاد باگ‌های غیرمنتظره می‌شود، خصوصاً اگر توانایی انجام آنها را نداشته باشد.

کلاس باید فقط اقداماتی انجام دهد که برای انجام نقش خود ضروری هستند. هر عملیات دیگر باید حذف شود یا اگر ممکن است توسط کلاس دیگری در آینده استفاده شود به جای دیگری منتقل گردد.

هدف

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

---

D — Dependency Inversion Principle (اصل وارونگی وابستگی)

• ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابستگی داشته باشند، هر دو باید به انتزاع (abstraction) وابسته باشند.
• انتزاع‌ها نباید به جزئیات وابسته باشند، جزئیات باید به انتزاع وابسته باشند.

اجازه دهید اصطلاحات را ساده کنیم:

• ماژول (کلاس) سطح بالا: کلاسی که عملی را با استفاده از ابزاری اجرا می‌کند.
• ماژول (کلاس) سطح پایین: ابزاری که برای اجرای عمل لازم است.
• انتزاع (Abstraction): اینترفیس (رابط)ی که این دو کلاس را به هم متصل می‌کند.
• جزئیات (Details): نحوه کار ابزار

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

همچنین می‌گوید هم کلاس و هم اینترفیس نباید بدانند ابزار چگونه کار می‌کند، اما ابزار باید مشخصات این اینترفیس را پیاده‌سازی کند.

هدف

هدف این اصل کاهش وابستگی مستقیم کلاس سطح بالا به کلاس سطح پایین از طریق معرفی یک اینترفیس است.

---

خلاصه

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

از اینکه خواندید ممنونم. امیدوارم درباره این موضوع بهتر فهمیده باشید و به اندازه من از نوشتن این مقاله، لذت برده باشید.

اگر سوال یا پیشنهادی دارید، حتماً در بخش نظرات بنویسید.

برای کسانی که علاقه دارند از این تصویرسازی‌ها برای چاپ یا مقاصد حرفه‌ای استفاده کنند، لطفاً حمایت مالی از هنرمند را در نظر بگیرید. با این کار، دسترسی به دانلودهای با کیفیت بالا از طریق لینک زیر خواهید داشت:
https://payhip.com/b/Hvh57