آموزش اصول SOLID

مقدمه

اگر با برنامه نویسی شی‌گرا آشنا باشید به احتمال زیاد عبارت SOLID به گوشتان خورده  است. و ممکن است حتی با این اصول آشنایی داشته باشید. برای کسانی که با این عبارت آشنا نیستند، SOLID مجموعه ای از ۵ اصل در دنیای برنامه نویسی و شی‌گرا می‌باشند. که توسط آقای رابرت سی مارتین که ما برنامه‌نویس‌ها ایشان را عمو باب صدا می‌زنیم به وجود آمده‌اند. این اصول به ما کمک می‌کنند تا فرایند ساخت نرم افزار ساده و درعین حال توسعه‌پذیر باشد و بتوان براحتی از آن نگهداری کرد.مقالات آنلاین بیشماری در اینترنت در مورد اصول SOLID موجود است. ما در اینجا تصمیم گرفتیم که این اصول را به همراه تصاویر به زبانی ساده برای شما بیان کنیم.هدف اصلی ما در این مقاله این است که با استفاده از تصویر سازی و تاکید بر هدف هر اصل درکی بهتر از این اصول داشته باشیم.
در ادامه خواهید دید که برخی از این اصول ممکن است مشابه به نظر برسند اما هدف هر کدام کاملا با دیگری تفاوت دارد. احتمال دارد در حالی که یکی از اصول را رعایت می کنیم مجبور بشویم دیگری را نقض کنیم.
برای اینکه دنبال کردن موضوع آسان شود من از کلمه “کلاس” در این مقاله استفاده می‌کنم اما کلمه کلاس می‌تواند با کلماتی مانند تابع و ماژول هم جایگزین شود.

اصل اول (Single Responsibility)

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

هدف اصل اول

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

اصل دوم (Open-Closed)

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

هدف اصل دوم

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

اصل سوم (Liskov Substitution)

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

هدف اصل سوم

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

اصل چهارم (Interface Segregation)

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

هدف اصل چهارم

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

اصل پنجم (Dependency Inversion)

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

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

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

هدف اصل پنجم

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

تکمیلی

ممکن است فکر کنید برخی از این اصول باهم در تضاد هستند مثلا اصل Single Responsibility با اصل Open Closed در تضاد باشد. اول از همه اینکه هدف این مقاله این بود که هر کدام از این اصول رو به صورت مستقل بیان کند و در ادامه این دو اصل با هم در تضاد نیستند. یک کلاس قرار است یک مسئولیت را انجام بدهد و ممکن است برای انجام این مسئولیت عملکردهای مختلفی نیاز داشته باشد. پس این کلاس در کنار اینکه باید یک مسئولیت داشته باشد باید برای توسعه باز و برای تغییرات بسته باشد.

جمع بندی

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