SOLID هي خمس مبادئ تصميم لبناء أنظمة OOP قابلة للصيانة والمرونة. كل واحدة تعالج سبباً شائعاً للكود الصارم والهش.
| الحرف | المبدأ | المعنى بسطر واحد |
|---|
| S | Single Responsibility | يجب أن يكون للفئة سبب واحد للتغيير |
| O | Open/Closed | مفتوحة للتوسع، مغلقة للتعديل |
| L | Liskov Substitution | يجب أن تكون الأنواع الفرعية قابلة للاستخدام في أي مكان يُستخدم فيه النوع الأساسي |
| I | Interface Segregation | واجهات صغيرة متعددة أفضل من واجهة واحدة ضخمة |
| D | Dependency Inversion | اعتمد على التجريدات، وليس على الفئات الحقيقية |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService لا تعتمد على البريد الإلكتروني بشكل محدد — يمكنك التبديل إلى SMS أو اختبار مزيف دون لمس الفئة (D). إضافة نوع notifier جديد لا تحتاج إلى تغيير في OrderService (O).
SOLID هو إرشاد، وليس قانون. الإفراط في تطبيقه — واجهة لكل فئة، مستويات غير مباشرة في كل مكان — ينتج "حساء تجريد" يصعب متابعته أكثر من المشكلة التي حلها.
SOLID يوفر لغة تشخيصية مشتركة: يمكن للمراجعين تسمية السبب الذي يجعل الفئة صعبة التغيير ("هذا ينتهك SRP") بدلاً من الجدال بناءً على الذوق.
عند التطبيق بحكم، تقلل المبادئ من التأثيرات المتسلسلة — التغييرات تبقى محلية، الميزات الجديدة تتوسع بدلاً من إعادة الكتابة، والاختبارات يمكنها استبدال الإنشاءات بالتبعيات الحقيقية.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع