Skip to content

Latest commit

 

History

History
83 lines (76 loc) · 6.48 KB

File metadata and controls

83 lines (76 loc) · 6.48 KB

منبع

🌱 اصل تک مسئولیتی (Single Responsibility Principle)

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

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

نکته: این اصل نه تنها توی سطح کلاس‌ها، بلکه توی سطح متدها و توابع هم می‌تونه اعمال بشه


منبع

🌱 اصل باز/بسته یا Open/Closed Principle

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

چه زمانی به یک کلاس می‌گیم باز؟
به کلاسی که بشه اون رو توسعه داد، بشه از اون extend کرد، متدها و پراپرتی‌های جدید اضافه کرد و ویژگی‌ها و رفتار اون رو تغییر داد، میگن باز.

چه زمانی به یک کلاس میگیم بسته؟
کلاسی که کامل باشه. یعنی 100% تست شده باشه که بتونه توسط بقیه کلاس‌ها استفاده بشه، پایدار باشه و در آینده تغییر نکنه. توی بعضی از زبان‌های برنامه‌نویسی یکی از راه‌های بسته نگه داشتن یک کلاس، استفاده از کلمه کلیدی final هست.


منبع

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

اگر S یک زیر کلاس از T باشه، آبجکت‌های نوع T باید بتونن بدون تغییر دادن کد برنامه با آبجکت‌های نوع S جایگزین بشن


منبع

🌱 اصل جداسازی اینترفیس‌ها یا Interface Segregation Principle

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


منبع

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

کلاس‌های سطح بالا نباید به کلاس‌های سطح پایین وابسته باشن؛ هر دو باید وابسته به انتزاع (Abstractions) باشن.

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

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

مفهوم انتزاع (Abstraction)
کلاس‌های انتزاعی کلاس‌های هستن که قابل پیاده‌سازی نیستن اما به عنوان یک طرح و الگو برای کلاس‌های دیگه در نظر گرفته میشن.


🌱 سیستم‌هایی که SOLID در آن رعایت نمی‌شود این ۴ مورد را همراه خود خواهند داشت

Rigidity
در واقع Rigidity یعنی ناتوانی در تغییر. /  اگر برای تغییر دادن بخش کوچکی از کد مجبور شویم کل سیستم را مجددا rebuild کنیم، آنوقت آن دچار Rigidty شده است.

Fragility
مفهوم Fragility و Rigidity بسیار بهم نزدیک اند. درواقع علت و معلول یکدیگر هستند. Fragility اشاره دارد به اینکه هر موقع تغییری در سیستم ایجاد می‌کنید در بخش (یا بخش‌های) دیگری از سیستم - که حتی هیچ ربطی با آن قسمت ندارد - با خطا و مشکل مواجه می‌شوید.

Immobility
نتوانیم آن قسمت از کد یا کامپوننت را در دیگر بخش‌های سیستم استفاده کنیم.

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