آموزش اصول SOLID در سی شارپ

اصول طراحی SOLID

اصول طراحی SOLID برای مدیریت اکثر مشکلات طراحی نرم افزار که ما، به عنوان توسعه دهنده، معمولاً در برنامه نویسی روزمره خود با آن ها مواجه می شویم، استفاده می شوند.

اصول SOLID، مکانیسم های اثبات شده ای هستند و روش های متعددی برای حذف کدهای tightly coupled بین اجزای نرم افزار ارائه می دهند.

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

مزایای به کارگیری اصول SOLID در طراحی نرم افزار:

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

Single Responsibility Principle یا اصل تک وظیفه ای

SRP بیان می کند که یک کلاس باید فقط یک دلیل برای تغییر داشته باشد، به این معنی که کلاس فقط یک وظیفه یا مسئولیت داشته باشد.

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

بنابراین، ما باید نرم افزار را به گونه ای طراحی کنیم که همه چیز در یک کلاس به یک مسئولیت واحد مرتبط باشد.

با استفاده از SRP کلاس ها کوچک تر، تمیزتر و نگهداری آن ها آسان تر می شود.

مزایای پیروی کردن از Single Responsibility Principle:

• درک آسان تر کد: کلاس هایی که تنها یک مسئولیت دارند، معمولاً کوچک تر و متمرکزتر هستند که باعث می شود درک آن ها آسان تر شود. هر کلاس هدف مشخصی دارد، بنابراین توسعه دهندگان می توانند به سرعت بفهمند که این کلاس چه کاری انجام می دهد.
• اصلاح آسان تر کد: وقتی کلاس ها فقط با یک مسئولیت طراحی می شوند، تغییرات بر اجزای کمتری تأثیر می گذارد.
• تست آسان تر: SRP منجر به کلاس های کوچک تری می شود که عموماً تست آن ها آسان تر است. هر تست می تواند روی یک عملکرد واحد تمرکز کند که پیچیدگی موارد تست را کاهش می دهد. این امر همچنین نوشتن و درک Unit Tests را ساده تر می کند.
• افزایش قابلیت استفاده مجدد: کلاس هایی که فقط مسئول یک عملکرد هستند، احتمال بیشتری دارد که در سایر بخش های برنامه یا حتی در پروژه های مختلف دوباره استفاده شوند.

Open-Closed Principle یا اصل باز و بسته

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

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

بسته برای اصلاح به این معنی است که ما نباید اجزای نرم افزار را تا زمانی که اشکالاتی پیدا نکرده ، تغییر دهیم. اما چرا مهم است؟

تغییر کدهای موجود خطرناک است چون ممکن است باعث ایجاد باگ شود.

فرض کنید که ما قبلاً یک کلاس را توسعه داده ایم که مرحله تست را پشت سر گذاشته است. بنابراین نباید مجبور باشیم این را تغییر دهیم زیرا بر عملکردهای موجود تأثیر می گذارد.

این اصل این ایده را ترویج می دهد که شما باید بتوانید بدون تغییر کد موجود، قابلیت های جدیدی را به یک کامپوننت اضافه کنید.

برای پیاده سازی OCP معمولاً از انتزاع ها (Abstract Classes یا Interfaces) استفاده می کنیم.

مزایای پیروی کردن از Open-Closed Principle:

• کاهش باگ ها: با پیروی از OCP، کد موجود هنگام اضافه شدن ویژگی های جدید بدون تغییر باقی می ماند. این امر به طور قابل توجهی خطر ایجاد باگ در کد موجود را کاهش می دهد و پایداری و قابلیت اطمینان را تضمین می کند.
• بهبود قابلیت نگهداری: از آنجایی که عملکرد اصلی ماژول های موجود تغییر نمی کند، نگهداری برنامه ساده تر می شود. اصلاحات با اضافه کردن کد جدید به جای تغییر کد قدیمی انجام می شود که به حفظ کد تمیز و سازمان یافته کمک می کند.
• استفاده موثر از مفهوم OOP: اعمال OCP اغلب منجر به استفاده از اینترفیس ها و کلاس های انتزاعی می شود و استفاده از inheritance و polymorphism را ترویج می دهد.

Liskov Substitution Principle یا اصل جایگزینی لیسکوف

این اصل بیان می کند که اشیاء یک BaseClass باید بدون تأثیر بر رفتار برنامه، با اشیاء SubClass آن قابل تعویض باشند. این بدان معناست که یک SubClass باید کاملاً به رفتار مورد انتظار BaseClass پایبند باشد. بنابراین اصل LSP طرحی را ترویج می کند که در آن SubClass ها قابل تعویض با BaseClass خود باشند.

به عبارت ساده، می توان گفت وقتی روابط وراثت بین دو کلاس داریم، اگر با موفقیت نمونه یک BaseClass را با یک نمونه از SubClass جایگزین کنیم، بدون اینکه بر رفتار نمونه BaseClass تأثیر بگذارد، از اصل جایگزینی لیسکوف پیروی می کنیم.

مزایای پیروی کردن از Liskov substitution Principle:

• این اصل باعث می شود کد قابل تعمیم و توسعه باشد.
• تضمین می کند که SubClass ها رفتار BaseClass خود را نقض نکنند.
• به نگهداری، تست و خوانایی کد کمک می کند.

Interface Segregation Principle یا اصل تفکیک اینترفیس ها

این اصل بیان می کند که:

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

مزایای پیروی کردن از Interface Segregation Principle:

• Reduced Side Effects: با جداسازی اینترفیس ها، تغییرات در یک بخش از سیستم، احتمال کمتری دارد که بر کلاس هایی که این اینترفیس ها را پیاده سازی می کنند، تأثیر بگذارد. کلاینت ها فقط از متدهایی که به آن ها مربوط هستند، مطلع می شوند، بنابراین تغییرات در متدهای غیرمرتبط، تأثیری بر آن ها نخواهد گذاشت.
• افزایش وضوح و تمرکز: اینترفیس های کوچک تر، درک و پیاده سازی آسان تری دارند و هر اینترفیس بر یک جنبه خاص تمرکز دارد.
• نگهداری و توسعه آسان تر: با اینترفیس های کوچک تر و تفکیک شده، نگهداری و توسعه نرم افزار ساده تر می شود. توسعه دهندگان می توانند بدون تغییر اینترفیس های موجود، صرفاً با ایجاد اینترفیس های جدید و پیاده سازی چندین اینترفیس توسط کلاس ها در صورت نیاز، قابلیت های جدیدی اضافه کنند.
• قابلیت استفاده مجدد: اینترفیس های تفکیک شده، قابلیت استفاده مجدد را افزایش می دهند. از آنجایی که هر اینترفیس کوچک تر و خاص تر است، می توان آن را به راحتی در بخش های مختلف یک سیستم یا حتی در پروژه های مختلف بدون حمل وابستگی های غیرضروری، دوباره استفاده کرد.
• تقویت Decoupling: این اصل به کاهش اتصال بین کلاس ها کمک می کند. این به کلاس های پیاده سازی اجازه می دهد تا فقط به اینترفیس هایی که واقعاً از آن ها استفاده می کنند وابسته باشند، که این امر وابستگی بین اجزا را به حداقل می رساند.

Dependency Inversion Principle یا اصل معکوس سازی وابستگی

DIP بیان می کند که ماژول ها/کلاس های سطح بالا نباید به ماژول ها/کلاس های سطح پایین وابسته باشند و هر دو باید به انتزاع ها (اینترفیس ها یا کلاس های انتزاعی) وابسته باشند. ثانیاً، انتزاع ها نباید به جزئیات وابسته باشند و جزئیات باید به انتزاع ها وابسته باشند.

DIP این ایده رو ترویج می کند که همیشه ماژول های سطح بالا و سطح پایین را تا حد امکان به صورت loosely coupled نگه دارید.

مزایای پیروی کردن ازDependency Inversion Principle:

• کاهش وابستگی بین ماژول ها: با وابستگی به انتزاع ها، ماژول ها کمتر به هم وابسته می شوند. این کاهش وابستگی، اصلاح و توسعه برنامه را بدون تأثیر بر سایر بخش های برنامه آسان تر می کند.
• نگهداری و به روزرسانی آسان تر: از آنجایی که ماژول های سطح بالا به ماژول های سطح پایین وابسته نیستند، به روزرسانی ها یا تغییرات در جزئیات پیاده سازی یک برنامه، نیازی به تغییر در ماژول های سطح بالا ندارد. این جداسازی، نگهداری و تعریف قابلیت های جدید را ساده می کند.
• توسعه موازی را تسهیل می کند: از آنجایی که اجزا از هم جدا شده اند و از طریق انتزاع ها با هم تعامل دارند، بخش های مختلف برنامه می توانند به صورت موازی توسعه داده شوند. تیم ها می توانند به طور همزمان روی اجزای جداگانه کار کنند، بدون اینکه منتظر بمانند دیگران وظایف خود را انجام دهند، که این امر روند توسعه را سرعت می بخشد.

این دوره برای تمامی برنامه نویسان و مهندسان نرم افزار که تمایل دارند سطح مهارت های طراحی خود را ارتقاء دهند، مناسب است. فارغ از زبان برنامه نویسی یا تکنولوژی مورد استفاده، اصول SOLID پایه ای مشترک و قدرتمند برای طراحی کدهای تمیز و حرفه ای فراهم می کند.

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