اصول S.O.L.I.D

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

اگر می‌خواهید نرم افزاری بسازید که قابل توسعه و نگهداری باشد این پنج اصل را دنبال کنید؛ این راهکار ها توسط Robert C. Martin به شهرت رسیدند.

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

بنابراین هدف اصلی این مقاله درک بهتر این اصول به همراه تصاویر و تاکید به هدف هر اصل می‌باشد.

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

برای ساده کردن این پروسه من از واژه class استفاده می‌کنم اما به خاطر داشته باشید که در این مقاله این قواعد ممکن است به یک Function,Method یا Module نیز کاربرد داشته باشد.

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

همچنین مسئولیت با رفتار‌ متفاوت است. در SRP، از "I am painter" استفاده کردم اما در Open Closed، از "I can paint" استفاده کردم.

توجه به این نکات حائز اهمیت است زیرا چندین عمل برای تحقق یک مسئولیت قابل انجام است. کلاس باید یک مسئولیت داشته باشد اما متد‌های باید برای توسعه باز باشد.

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

اصول SOLID

 - SSingle Responsibility

یک کلاس باید تنها یک وظیفه داشته باشد.

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

هدف

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

Open-Closed - O

کلاس باید برای توسعه باز و برای اصلاحات بسته باشد.

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

هدف

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

Liskov Substitution - L

اگر S  یک زیرمجموعه از T باشد، object از نوع T در یک برنامه ممکن است با object از نوع S جایگزین شوند بدون اینکه هیچ یک از خصوصیات درخواستی آن را داشته باشد.

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

اگر کلاسی دارید و کلاس دیگری از آن ایجاد می‌کنید این کلاس پدر می‌شود و کلاس جدید کلاس فرزند می‌شود. کلاس فرزند باید بتواند کارهایی را انجام دهد که کلاس پدر می‌تواند انجام دهد به این فرایند ارث‌بری یا وراثت گفته می‌شود.

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

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

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

هدف

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

Interface Segregation - I

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

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

یک کلاس فقط باید اقدامات لازم مربوط به مسئولیت خود را بر‌عهده بگیرد؛ اگرچه ممکن است در آینده توسط یک کلاس دیگر استفاده شود یا هر عمل دیگری، باید کاملاً برداشته شود یا به جای دیگر منتقل شود.

هدف

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

Dependency Inversion - D

• ماژول‌های پیشرفته نباید به ماژول‌های ساده وابستگی داشته باشند، بلکه هر دو باید به abstraction اتکا کنند.
• abstraction نباید به جزئیات وابستگی داشته باشد؛ جزئیات باید به abstraction وابستگی داشته باشند.

اولا ما نمی‌خواهیم اصولی که اینجا استفاده شده است را ساده‌تر بیان کنیم:

High-level Module (or Class): کلاسی  که عملی را با یک ابزار پیاده سازی می‌کند

Low-level Module (or Class): ابزاری که برای پیاده‌‌سازی عمل به آن نیاز است

Abstraction: نشان دهنده interface است که دو کلاس را به هم متصل می‌کند

Details: نحوه کار این ابزار

این اصل به ما این را می‌گوید که یک کلاس نباید با ابزاری که برای پیاده‌سازی یک عمل از آن استفاده شده است را با‌هم ترکیب کرد. بلکه باید با interface ترکیب شود تا به ابزار اجازه‌ی اتصال به کلاس را بدهد.

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

هدف

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

خلاصه

تا اینجا به پنج اصل SOLID پرداختیم و اهداف آن‌ها را بررسی کردیم.آن‌ها به شما کمک می‌کنند تا کدهای خود را ساده‌تر، گسترش پذیرتر و تست برنامه را با کم‌ترین مشکل انجام دهید برای آشنایی و درک بهتر من به شما دوره اصول طراحی شي‌گرا SOLID را معرفی می‌کنم.

منبع