آشنایی با اصول .S.O.L.I.D (مقدمه):

با عرض سلام و احترام.
پیشاپیش از شما دوست عزیز و گرامی، بابت وقتی که برای مطالعه ی این مطلب خواهید گذاشت، سپاسگزارم.
تقاضا دارم، در صورت مشاهده ی اشتباه متنی یا محتوایی، به اینجانب اطلاع دهید تا (ضمن کمک به یادگیری بنده) در اسرع وقت برای اصلاح متن اقدام نمایم.
شماره ی تماس:
09215149218
نشانی پست الکترونیکی:
RezaQadimi.ir@Gmail.com
آدرس سایت ها:
https://Reza-Qadimi.ir - https://WannaDate.ir

استفاده از اصول SOLID، باعث نوشتن کدهایی با کارایی بالا می شوند.

هدف من در این مقاله، آشنایی مقدماتی شما با این اصول بوده، و توضیحات تکمیلی مربوط به هر یک از آنها، در مقالات بعدی (به همراه مثال) ارائه خواهد شد.

مقدمه:

احتمالا این موضوع برای شما هم پیش آمده (یا در آینده پیش خواهد آمد) که پروژه ای نوشته باشید (یا بعضا از دیگران تحویل گرفته باشید)، که نیازمند توسعه و پشتیبانی است.

ممکن است پس از گذشت چند سال (و یا حتی چند ماه از اتمام پروژه)، شرایطی بوجود بیاید که مجبور به تغییر در ساختار این پروژه و افزودن ویژگی جدید به آن شوید.

در صورت عدم آشنایی شما با این اصول (چه به صورت ذاتی، و چه از طریق یادگیری)، احتمالا پس از گذاشتن چند دقیقه/ساعت وقت، به این نتیجه برسید که نوشتن مجدد پروژه، از توسعه ی آن، هزینه ی کمتری خواهد داشت!

اصول SOLID، مفاهیم 5 گانه ای هستند (دقت کنید: اصول SOLID، نه الگوهای طراحی!)، که توسط Robert C. Martin (Uncle Bob)، در سال 2000 ارائه شدند.

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

در ادامه، به صورت مختصر، به بررسی هر کدام از این موارد می پردازیم.

همانطور که احتمالا تا به این لحظه متوجه شده اید، هر کدام از حروف SOLID، کوتاه شده ی یک عبارت می باشند.

مفهوم SOLID شامل 5 اصل زیر است:

S: Single Responsibility Principle

O: Open/Closed Principle

L: Liskov Substitution Principle

I: Interface Segregation Principle

D: Dependency Inversion Principle

• Single Responsibility Principle:

اصل اول: ماژول ها باید تک وظیفه ای باشند (یا به عبارتی هر ماژول باید صرفا و فقط یک دلیل برای تغییر داشته باشد).

• Open/Closed Principle:

اصل دوم: ماژول های پروژه ی ما، باید برای گسترش "باز"، و برای تغییر "بسته" باشند (امکان توسعه داشته باشند، اما اجازه ی تغییر را نه).

• Liskov Substitution Principle:

اصل سوم: کلاس والد، باید مناسب تمامی کلاس هایی باشد که از آن ارث بری میکنند (به عبارتی، زمانی که یک کلاس از کلاسی دیگر ارث بری می کند، نباید رفتار کلاس والد/پدر خود را تغییر دهد).

• Interface Segregation Principle:

اصل چهارم: نباید از Interface (یا abstract class) هایی استفاده کنیم که "بیش از حد" چاق هستند (رفتارها و ویژگی هایی دارند، که در تمامی کلاس هایی که از آن ارث بری میکنند، مورد نیاز نیست)، و بهتر است به جای آن، بر اساس نیازمندی های مختلف، اینترفیس های جداگانه ای داشته باشیم.

• Dependency Inversion Principle:

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

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

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