SOLID Principles: عندما ينهار الكود تحت وطأة التغييرات الصغيرة

في أحد أيام الجمعة، تلقيت مكالمة طارئة من فريق الدعم: السيرفر ينهار تحت ضغط ٥٠٠ مستخدم متزامن. المشكلة؟ تعديل بسيط في منطق الخصومات تسبب في فشل كامل لنظام الفوترة. الكود كان "يعمل" منذ سنتين، لكن أي تغيير أصبح كابوساً. الحقيقة المؤلمة: الكود لم يكن يتبع SOLID Principles، بل كان كتلة متشابكة من الـ if-else والـ hard-coded values. عندما حاولت إضافة خصم جديد، اضطررت لتعديل ١٢ ملفاً مختلفاً، وكل تعديل كان يكسر شيئاً آخر. هذه ليست مأساة فردية - إنها واقع ٨٠٪ من المشاريع التي أراجعها.

المشكلة الحقيقية ليست في معرفة مبادئ SOLID، بل في تطبيقها بشكل عملي دون تحويل الكود إلى متاهة من الـ interfaces والـ abstractions الفارغة. معظم المطورين يقرؤون عن Single Responsibility Principle ثم يكتبون كلاساً واحداً مسؤولاً عن كل شيء من الـ database connection إلى الـ UI rendering. في هذا المقال، سأريك كيف تبدو SOLID في الكود الحقيقي - ليس الأكواد التافهة التي تجدها في الدروس، بل الأمثلة المعقدة التي تواجهها يومياً في الإنتاج.

Single Responsibility: عندما يصبح الكلاس مثل سكين الجيش السويسري

لنبدأ بمثال واقعي من نظام إدارة المستشفيات. الكلاس التالي كان مسؤولاً عن كل شيء يتعلق بالمريض: تسجيل البيانات، حساب الفواتير، إرسال الإشعارات، وحتى توليد التقارير. النتيجة؟ كلاس بـ ١٢٠٠ سطر و٥٠ دالة، وكل تعديل فيه كان يتطلب اختبار النظام بالكامل. هذا ليس كلاس، بل هو قنبلة موقوتة.

// قبل: الكلاس الوحش
class PatientManager {
 constructor(private db: Database) {}

 registerPatient(patient: Patient): void {
 // منطق التسجيل
 this.db.save(patient);
 this.sendWelcomeEmail(patient.email);
 this.generateInitialReport(patient.id);
 }

 calculateBill(patientId: string): number {
 // منطق معقد للفواتير
 const services = this.db.getServices(patientId);
 return services.reduce((sum, s) => sum + s.price, 0);
 }

 sendNotification(patientId: string, message: string): void {
 const patient = this.db.getPatient(patientId);
 this.emailService.send(patient.email, message);
 }

 // + 47 دالة أخرى...
}

// المشكلة: أي تغيير في منطق الفواتير يتطلب اختبار كل الدوال الأخرى
// لأن الكلاس مسؤول عن كل شيء

الحل ليس في تقسيم الكلاس عشوائياً، بل في تحديد المسؤوليات الحقيقية. في هذا المثال، يمكننا تقسيم الكلاس إلى ثلاث فئات: PatientRepository للتعامل مع قاعدة البيانات، BillingService لحساب الفواتير، وNotificationService لإرسال الإشعارات. لكن التحول الحقيقي يأتي عندما نفهم أن كل خدمة يجب أن تكون مستقلة تماماً - حتى لو تطلب ذلك إعادة تصميم الـ database schema.

// بعد تطبيق SRP
class PatientRepository {
 constructor(private db: Database) {}

 save(patient: Patient): void {
 this.db.save(patient);
 }

 getById(id: string): Patient | null {
 return this.db.getPatient(id);
 }
}

class BillingService {
 constructor(private repo: PatientRepository) {}

 calculate(patientId: string): number {
 const services = this.repo.getServices(patientId);
 return services.reduce((sum, s) => sum + s.price, 0);
 }
}

class NotificationService {
 constructor(private repo: PatientRepository, private emailService: EmailService) {}

 send(patientId: string, message: string): void {
 const patient = this.repo.getById(patientId);
 if (patient) this.emailService.send(patient.email, message);
 }
}

// الآن: تغيير منطق الفواتير لا يؤثر على إرسال الإشعارات
// وكل خدمة يمكن اختبارها بشكل مستقل

المفتاح هنا هو فهم أن المسؤولية لا تعني "مهمة واحدة" بل "سبب واحد للتغيير". في المثال السابق، PatientRepository قد يحتوي على عدة دوال للتعامل مع قاعدة البيانات، لكن كلها تتغير لنفس السبب: تغيير الـ schema أو طريقة التخزين. بينما BillingService تتغير فقط عندما يتغير منطق الفواتير. هذا الفهم العميق هو ما يميز التطبيق العملي لـ SRP عن مجرد تقسيم الكود عشوائياً.

Open/Closed Principle: عندما تصبح الإضافات كابوساً بدلاً من ميزة

في نظام التجارة الإلكترونية الذي عملت عليه، كان لدينا نظام خصومات معقد. في البداية، كان الكود بسيطاً: خصم نسبة مئوية أو مبلغ ثابت. لكن مع الوقت، أضفنا خصومات معقدة مثل "اشترِ منتجين واحصل على الثالث مجاناً" و"خصم خاص للعملاء الجدد". كل إضافة كانت تتطلب تعديل الكلاس الرئيسي، مما أدى إلى كود مليء بـ if-else متداخلة. في إحدى المرات، تسبب تعديل بسيط في كسر عملية الدفع بالكامل لأن أحد الشروط الجديدة لم يتم اختبارها جيداً.

# قبل: الكلاس المغلق للتعديل
class DiscountCalculator:
 def calculate(self, order: Order, discount_type: str, value: float) -> float:
 if discount_type == "percentage":
 return order.total * (value / 100)
 elif discount_type == "fixed":
 return value
 elif discount_type == "buy2_get1_free":
 # منطق معقد يعتمد على عدد المنتجات
 eligible_items = [i for i in order.items if i.category == "electronics"]
 return len(eligible_items) // 3 * eligible_items[0].price if eligible_items else 0
 elif discount_type == "new_customer":
 return 10 if order.customer.is_new else 0
 # + 7 أنواع خصومات أخرى...
 
 return 0

# المشكلة: إضافة خصم جديد يتطلب تعديل الدالة الرئيسية
# وكل تعديل يزيد من احتمال حدوث أخطاء

الحل الحقيقي لـ OCP ليس في إضافة المزيد من الـ if-else، بل في تصميم النظام بحيث يمكن إضافة ميزات جديدة دون تعديل الكود الموجود. في هذا المثال، يمكننا استخدام نمط Strategy Pattern لإنشاء واجهة موحدة للخصومات، ثم تنفيذ كل نوع خصم ككلاس مستقل. هذا ليس مجرد تحسين تجميلي - إنه تغيير جوهري في طريقة تعاملنا مع الإضافات المستقبلية.

# بعد تطبيق OCP
from abc import ABC, abstractmethod

class DiscountStrategy(ABC):
 @abstractmethod
 def calculate(self, order: Order) -> float:
 pass

class PercentageDiscount(DiscountStrategy):
 def __init__(self, percentage: float):
 self.percentage = percentage
 
 def calculate(self, order: Order) -> float:
 return order.total * (self.percentage / 100)

class Buy2Get1FreeDiscount(DiscountStrategy):
 def calculate(self, order: Order) -> float:
 eligible_items = [i for i in order.items if i.category == "electronics"]
 return len(eligible_items) // 3 * eligible_items[0].price if eligible_items else 0

class DiscountCalculator:
 def __init__(self, strategy: DiscountStrategy):
 self.strategy = strategy
 
 def calculate(self, order: Order) -> float:
 return self.strategy.calculate(order)

# الاستخدام:
calculator = DiscountCalculator(Buy2Get1FreeDiscount())
discount = calculator.calculate(order)

# إضافة خصم جديد لا يتطلب تعديل الكلاس الرئيسي
class NewCustomerDiscount(DiscountStrategy):
 def calculate(self, order: Order) -> float:
 return 10 if order.customer.is_new else 0

الميزة الحقيقية لهذا التصميم تظهر عندما تريد إضافة خصم جديد. بدلاً من تعديل كلاس موجود (ومخاطرة بكسر شيء ما)، يمكنك ببساطة إنشاء كلاس جديد وتنفيذه. هذا ليس مجرد تحسين في قابلية الصيانة، بل هو تغيير في طريقة تفكيرنا: الكود يجب أن يكون مفتوحاً للتوسعة لكن مغلقاً للتعديل. في مشاريع الإنتاج، هذا يعني أن فريقين مختلفين يمكنهما العمل على ميزات جديدة دون الحاجة إلى تعديل نفس الملفات، مما يقلل بشكل كبير من احتمالية حدوث conflicts في الـ git.

Liskov Substitution Principle: عندما تكذب الوراثة على المطورين

في أحد المشاريع، كان لدينا نظام لإدارة المستندات مع كلاس Document أساسي وعدة كلاسات فرعية مثل PDFDocument وWordDocument. الكلاس الأساسي كان يحتوي على دالة save() التي تعمل بشكل جيد مع المستندات العادية. لكن عندما أضفنا كلاس ReadOnlyDocument، واجهنا مشكلة: دالة save() كانت ترمي خطأ عند محاولة الحفظ. المطور الذي كتب الكود ظن أن هذا مقبول لأن "المستندات للقراءة فقط لا تحتاج للحفظ". النتيجة؟ كل الكود الذي كان يستخدم Document بدأ يفشل عندما نمرر له ReadOnlyDocument.

// قبل: انتهاك LSP
class Document {
 public void save() {
 // منطق الحفظ
 }
}

class ReadOnlyDocument extends Document {
 @Override
 public void save() {
 throw new UnsupportedOperationException("Cannot save read-only document");
 }
}

// المشكلة: الكود التالي يفشل عند استخدام ReadOnlyDocument
public void processDocument(Document doc) {
 // بعض العمليات...
 doc.save(); // قد يفشل إذا كان doc من نوع ReadOnlyDocument
}

الحل ليس في إضافة شروط للتحقق من نوع الكلاس، بل في إعادة تصميم التسلسل الهرمي بحيث لا تكذب الكلاسات الفرعية على المطورين. في هذا المثال، يمكننا فصل مفهوم الحفظ إلى واجهة منفصلة، وجعل ReadOnlyDocument لا ينفذ هذه الواجهة. هذا ليس مجرد حل تقني، بل هو تغيير في طريقة تفكيرنا حول الوراثة: الكلاسات الفرعية يجب أن تكون قابلة للاستبدال بالكامل بالكلاس الأساسي دون كسر الكود.

// بعد تطبيق LSP
interface Savable {
 void save();
}

class Document implements Savable {
 @Override
 public void save() {
 // منطق الحفظ
 }
}

class ReadOnlyDocument extends Document {
 // لا ينفذ save() - ليس مسؤولاً عن الحفظ
}

// الآن: الكود التالي يعمل بشكل آمن
public void processDocument(Document doc) {
 // بعض العمليات...
 if (doc instanceof Savable) {
 ((Savable) doc).save();
 }
}

المشكلة الحقيقية هنا ليست في الكود نفسه، بل في العقلية التي تسمح للكلاسات الفرعية بتغيير السلوك المتوقع. في مشاريع الإنتاج، هذا النوع من المشاكل يظهر غالباً عندما نستخدم الوراثة لمجرد إعادة الاستخدام بدلاً من التعبير عن علاقة "هو-نوع-من". الحل الحقيقي يأتي عندما نفهم أن LSP ليس مجرد قاعدة لتجنب الأخطاء، بل هو أداة لتصميم أنظمة أكثر موثوقية وقابلة للتنبؤ.

Interface Segregation Principle: عندما تصبح الواجهات مثل الفاتورة الحكومية

في نظام إدارة المحتوى الذي عملت عليه، كان لدينا واجهة ضخمة تسمى ContentManager تحتوي على أكثر من ٣٠ دالة للتعامل مع كل شيء من إنشاء المحتوى إلى إدارة المستخدمين. النتيجة؟ كل كلاس كان ينفذ هذه الواجهة كان مضطراً لتوفير دوال لا يحتاجها أبداً. على سبيل المثال، كلاس UserProfileManager كان مضطراً لتنفيذ دوال مثل createArticle() وdeleteComment() رغم أنه لا علاقة له بالمحتوى. هذا لم يجعل الكود أكثر تعقيداً فحسب، بل جعله أيضاً أكثر عرضة للأخطاء عند إجراء التغييرات.

// قبل: واجهة ضخمة واحدة
public interface IContentManager {
 void CreateArticle(Article article);
 void DeleteArticle(int id);
 void PublishArticle(int id);
 void CreateComment(Comment comment);
 void DeleteComment(int id);
 void AddUser(User user);
 void RemoveUser(int id);
 // + 25 دالة أخرى...
}

// المشكلة: كلاس UserProfileManager مضطر لتنفيذ دوال لا يحتاجها
public class UserProfileManager : IContentManager {
 public void CreateArticle(Article article) {
 throw new NotImplementedException();
 }
 
 public void DeleteArticle(int id) {
 throw new NotImplementedException();
 }
 
 // + 28 دالة أخرى غير مستخدمة
}

الحل الحقيقي لـ ISP ليس في تقسيم الواجهة إلى واجهات أصغر عشوائياً، بل في فهم احتياجات العملاء الحقيقيين. في هذا المثال، يمكننا تقسيم IContentManager إلى واجهات أصغر وأكثر تخصصاً مثل IArticleManager وICommentManager وIUserManager. لكن الأهم من ذلك هو فهم أن الواجهات يجب أن تصمم بناءً على ما يحتاجه العملاء، وليس بناءً على ما نعتقد أنه قد يحتاجونه في المستقبل.

// بعد تطبيق ISP
public interface IArticleManager {
 void CreateArticle(Article article);
 void DeleteArticle(int id);
 void PublishArticle(int id);
}

public interface ICommentManager {
 void CreateComment(Comment comment);
 void DeleteComment(int id);
}

public interface IUserManager {
 void AddUser(User user);
 void RemoveUser(int id);
}

// الآن: كلاس UserProfileManager ينفذ فقط ما يحتاجه
public class UserProfileManager : IUserManager {
 public void AddUser(User user) {
 // منطق إضافة المستخدم
 }
 
 public void RemoveUser(int id) {
 // منطق إزالة المستخدم
 }
}

الميزة الحقيقية لهذا التصميم تظهر عندما تريد تغيير سلوك معين. بدلاً من البحث في كلاس واحد ضخم، يمكنك التركيز على الواجهة الصغيرة ذات الصلة. في مشاريع الإنتاج، هذا يعني أن التغييرات تصبح أكثر أماناً وأسرع، لأنك تقلل من احتمالية التأثير على أجزاء أخرى من النظام. لكن الأهم من ذلك هو أن هذا التصميم يجبرك على التفكير بعناية في مسؤوليات كل مكون، مما يؤدي إلى نظام أكثر تماسكاً وتنظيماً.

Dependency Inversion Principle: عندما يصبح الكود مثل شبكة عنكبوت

في أحد المشاريع الكبيرة، كان لدينا نظام يعتمد بشكل مباشر على مكتبة خارجية لإرسال الإشعارات. الكلاس الرئيسي كان ينشئ مثيلاً من هذه المكتبة مباشرة داخل الدوال، مما جعل من المستحيل تقريباً استبدال المكتبة أو اختبار الكود بشكل فعال. عندما قررنا التبديل إلى خدمة إشعارات جديدة، اضطررنا لتعديل أكثر من ٤٠ ملفاً، وكل تعديل كان يحمل خطر إدخال أخطاء جديدة. المشكلة لم تكن في المكتبة نفسها، بل في الطريقة التي تم بها دمجها في النظام.

// قبل: اعتماد مباشر على المكتبة
class NotificationService {
 sendEmail(to: string, subject: string, body: string): void {
 const mailer = new ExternalEmailLibrary();
 mailer.send(to, subject, body);
 }
 
 sendSMS(to: string, message: string): void {
 const smsClient = new ExternalSMSLibrary();
 smsClient.send(to, message);
 }
}

// المشكلة: لا يمكن استبدال المكتبة دون تعديل الكلاس
// ولا يمكن اختبار الكود دون إرسال إشعارات حقيقية

الحل الحقيقي لـ DIP ليس في إضافة طبقة تجريدية عشوائية، بل في فهم أن الطبقات العليا يجب ألا تعتمد على الطبقات الدنيا مباشرة. في هذا المثال، يمكننا إنشاء واجهة تجريدية تمثل خدمة الإشعارات، ثم جعل NotificationService يعتمد على هذه الواجهة بدلاً من المكتبة المباشرة. هذا ليس مجرد تحسين في قابلية الصيانة، بل هو تغيير في طريقة تصميم الأنظمة: الاعتماد يجب أن يكون على التجريدات، وليس على التفاصيل.

// بعد تطبيق DIP
interface INotificationService {
 sendEmail(to: string, subject: string, body: string): Promise<void>;
 sendSMS(to: string, message: string): Promise<void>;
}

class EmailNotificationService implements INotificationService {
 async sendEmail(to: string, subject: string, body: string): Promise<void> {
 const mailer = new ExternalEmailLibrary();
 await mailer.send(to, subject, body);
 }
 
 async sendSMS(to: string, message: string): Promise<void> {
 throw new Error("SMS not supported by email service");
 }
}

class SMSNotificationService implements INotificationService {
 async sendEmail(to: string, subject: string, body: string): Promise<void> {
 throw new Error("Email not supported by SMS service");
 }
 
 async sendSMS(to: string, message: string): Promise<void> {
 const smsClient = new ExternalSMSLibrary();
 await smsClient.send(to, message);
 }
}

class NotificationManager {
 constructor(private service: INotificationService) {}
 
 async notifyUser(user: User, message: string): Promise<void> {
 if (user.preferences.email) {
 await this.service.sendEmail(user.email, "Notification", message);
 }
 if (user.preferences.sms) {
 await this.service.sendSMS(user.phone, message);
 }
 }
}

// الآن: يمكن استبدال خدمة الإشعارات دون تعديل NotificationManager
const service = new EmailNotificationService();
const manager = new NotificationManager(service);

الميزة الحقيقية لهذا التصميم تظهر عندما تريد اختبار الكود أو استبدال المكتبة. بدلاً من الاعتماد على مكتبة خارجية، يمكنك إنشاء mock implementation للواجهة واختبار الكود بشكل مستقل. في مشاريع الإنتاج، هذا يعني أن التغييرات تصبح أكثر أماناً وأسرع، لأنك تقلل من الاعتماد على التفاصيل التي قد تتغير. لكن الأهم من ذلك هو أن هذا التصميم يجبرك على التفكير في العلاقات بين المكونات، مما يؤدي إلى نظام أكثر مرونة وقابلية للتطوير.

خلاصة المهندس: SOLID ليست قواعد، بل عقلية

بعد أكثر من عشر سنوات في كتابة الكود، تعلمت أن SOLID ليست مجرد مجموعة من القواعد لتتبعها، بل هي عقلية للتفكير في التصميم. المبدأ الأساسي وراء كل هذه المبادئ هو واحد: جعل الكود أكثر قابلية للتغيير والصيانة. عندما تواجه مشكلة في التصميم، اسأل نفسك: "هل هذا الكود سهل التعديل؟ هل يمكنني إضافة ميزة جديدة دون كسر شيء آخر؟ هل يمكنني اختبار هذا الجزء بشكل مستقل؟" إذا كانت الإجابة لا، فهذا يعني أنك بحاجة لإعادة التفكير في التصميم.

نصيحة عملية أخيرة: لا تحاول تطبيق SOLID على كل شيء منذ البداية. ابدأ بالكود الذي يتغير كثيراً أو يسبب مشاكل متكررة، ثم طبق المبادئ تدريجياً. تذكر أن الهدف ليس كتابة الكود المثالي، بل كتابة كود يمكن صيانته وتطويره بسهولة. وعندما تجد نفسك تكتب كلاساً عملاقاً أو واجهة ضخمة، توقف واسأل: "هل هذا يتبع SOLID أم أنني فقط أكتب كوداً معقداً دون داع؟"