اصول SOLID
اصول SOLID مجموعهای از پنج اصل طراحی در برنامهنویسی شیءگرا هستند که به بهبود قابلیت نگهداری (Maintainability)، توسعهپذیری (Extensibility) و کاهش وابستگی (Coupling) در سیستم کمک میکنند.
این اصول بهویژه در طراحی لایههای زیرساخت، سرویسها و پکیجهای قابل استفاده مجدد اهمیت بالایی دارند.
1. Single Responsibility Principle (SRP)
هر کلاس باید فقط یک دلیل برای تغییر داشته باشد.
یعنی هر کلاس یا ماژول باید تنها یک مسئولیت مشخص را بر عهده بگیرد.
مزایا
- کاهش پیچیدگی
- تغییرات ایزوله
نشانه نقض
- کلاسهایی که همزمان چند کار انجام میدهند (مثلاً: Validation + DB + Logging)
2. Open/Closed Principle (OCP)
کد باید برای توسعه باز و برای تغییر بسته باشد.
به جای تغییر کد موجود، باید بتوان رفتار جدید را از طریق Extension اضافه کرد.
روشهای پیادهسازی
- استفاده از Interface
- استفاده از Strategy Pattern
- استفاده از Event / Listener
نشانه نقض
- تغییر مکرر در کلاسهای core برای اضافه کردن feature جدید
3. Liskov Substitution Principle (LSP)
زیرکلاسها باید بدون ایجاد مشکل، قابل جایگزینی با کلاس پایه باشند.
یعنی رفتار کلاس فرزند نباید قرارداد (Contract) کلاس والد را بشکند.
نشانه نقض
- override کردن متدی به شکلی که رفتار متفاوت یا غیرمنتظره ایجاد کند
- پرتاب Exception در حالی که کلاس پایه این رفتار را ندارد
4. Interface Segregation Principle (ISP)
به جای یک Interface بزرگ، چند Interface کوچک و هدفمند طراحی کنید.
کلاینت نباید مجبور شود متدهایی را پیادهسازی کند که به آنها نیاز ندارد.
مزایا
- کاهش وابستگیهای غیرضروری
- خوانایی بهتر API
نشانه نقض
- Interfaceهایی با متدهای زیاد و unrelated
5. Dependency Inversion Principle (DIP)
وابستگیها باید به Abstraction باشند، نه به Implementation.
ماژولهای سطح بالا و پایین باید هر دو به Interface وابسته باشند.
مزایا
- امکان جایگزینی Implementation بدون تغییر در Core
نشانه نقض
- استفاده مستقیم از کلاسهای concrete در سرویسها
نکات کاربردی در پروژههای واقعی
- در لایه Service و Infrastructure بیشترین استفاده از SOLID اتفاق میافتد
- استفاده بیش از حد از Abstraction میتواند باعث پیچیدگی غیرضروری شود (Over-Engineering)
- SOLID باید هدفمند استفاده شود، نه صرفاً برای “تمیز به نظر رسیدن کد”