Design Patterns: أيها ينقذ مشروعك وأيها مجرد زينة أكاديمية؟

كنت أتصفح كود مشروع قديم لشركة ناشئة في دبي، ووجدت ١٧ استخداماً مختلفاً للـ Singleton في ملف واحد. المبرمج السابق كتب في تعليق: "هنا نضمن وجود نسخة واحدة فقط من الـ Logger". المشكلة؟ الـ Logger كان يعلق الـ Event Loop لأن كل طلب كان ينتظر فتح الملف على القرص الصلب. الـ Singleton لم يكن الحل، بل كان الجريمة. هذه اللحظة جعلتني أفكر: كم من الـ Design Patterns التي نستخدمها يومياً هي في الحقيقة مجرد زينة أكاديمية تُعقد الكود بدلاً من تبسيطه؟

الـ Design Patterns ليست مجرد قوالب جاهزة ننسخها من كتاب GoF. هي أدوات لحل مشاكل حقيقية، لكن المشكلة تبدأ عندما نستخدمها لحل مشاكل غير موجودة أصلاً. مثلاً، الـ Abstract Factory يُستخدم عندما نحتاج إنشاء عائلات من الكائنات المرتبطة ببعضها، لكن في معظم المشاريع الصغيرة، استخدامه يشبه شراء طائرة خاصة للذهاب إلى السوبرماركت. في هذا المقال، سأفكك الأنماط التي أراها فعلياً في المشاريع الكبيرة، والأنماط التي أصبحت مجرد موضة برمجية بلا قيمة حقيقية.

الـ Singleton: البطل المزيف الذي يسرق ذاكرة السيرفر

الـ Singleton هو أشهر نمط في تاريخ البرمجة، وربما أكثرها سوء فهم. الفكرة تبدو بسيطة: ضمان وجود نسخة واحدة فقط من الكائن في التطبيق. لكن خلف هذه البساطة تكمن كارثة الأداء. عندما تستخدم الـ Singleton لإدارة موارد مشتركة مثل قواعد البيانات أو الـ Cache، فأنت في الحقيقة تخلق عنق زجاجة واحداً لكل طلبات المستخدمين. تخيل ١٠٠٠ مستخدم يحاولون الوصول إلى نفس الكائن في نفس اللحظة، كل واحد ينتظر الآخر حتى ينتهي. هذا بالضبط ما يحدث في الـ Event Loop عندما يكون الـ Singleton متزامناً.

في مشروع لشركة سعودية، كان لدينا نظام دفع يعتمد على الـ Singleton لإدارة الاتصالات مع البنك. المشكلة؟ كل مرة كان هناك خطأ في الشبكة، الـ Singleton كان يدخل في حالة انتظار لا نهائية، مما يعلق كل الطلبات الأخرى. الحل؟ استبدلناه بـ Dependency Injection بسيط واستخدمنا مكتبة مثل Redis للـ Cache بدلاً من الاعتماد على كائن واحد في الذاكرة. النتيجة: انخفض وقت الاستجابة من ٤ ثوانٍ إلى ٢٠٠ مللي ثانية. الـ Singleton لم يكن الحل، بل كان المشكلة.

// Singleton سيئ: يعلق الـ Event Loop
class Database {
 private static instance: Database;
 private constructor() {}
 
 public static getInstance(): Database {
 if (!Database.instance) {
 Database.instance = new Database();
 // هنا يحدث الـ Blocking Call
 Database.instance.connect();
 }
 return Database.instance;
 }
 
 private connect() {
 // اتصال متزامن بقاعدة البيانات
 // لو فشل، الكل ينتظر
 }
}

// الحل الأفضل: Dependency Injection
class DatabaseService {
 constructor(private dbClient: DbClient) {}
 
 async query(sql: string) {
 return this.dbClient.query(sql);
 }
}
// استخدام:
const db = new DatabaseService(new PostgresClient());

الـ Singleton ليس سيئاً دائماً، لكنه غالباً ما يُستخدم في المكان الخطأ. استخدمه فقط للموارد التي يجب أن تكون وحيدة حقاً، مثل الـ Configuration أو الـ Logging (مع الحرص على عدم حظر الـ Event Loop). إذا كنت تستخدمه لإدارة الحالة المشتركة بين المستخدمين، فأنت تخلق مشكلة أكبر من التي تحاول حلها.

الـ Observer: عندما يصبح كل شيء حدثاً وكل حدث كارثة

الـ Observer هو نمط جميل نظرياً: كائنات تشترك في أحداث تحدث في كائن آخر. لكن في الواقع، عندما تستخدمه لكل شيء، يصبح نظامك أشبه بغرفة دردشة مفتوحة حيث كل شخص يصرخ في نفس الوقت. في مشروع لشركة إماراتية، كان لدينا نظام إشعارات يعتمد بشكل كامل على الـ Observer. المشكلة؟ عندما كان هناك ١٠ آلاف مستخدم متصلين، كل حدث صغير (مثل تغيير حالة طلب) كان يرسل ١٠ آلاف إشعار في نفس اللحظة، مما يسبب تحميلاً زائداً على السيرفر.

الـ Observer يصبح خطيراً عندما نستخدمه لإدارة تدفق البيانات بدلاً من مجرد إشعارات بسيطة. مثلاً، استخدامه لتحديث واجهة المستخدم في تطبيق React هو فكرة سيئة، لأنك ستخلق سلسلة من الـ Re-renders غير الضرورية. بدلاً من ذلك، استخدم مكتبات مثل Redux أو Zustand لإدارة الحالة بشكل مركزي، واترك الـ Observer للأحداث الحقيقية مثل إشعارات النظام أو الـ Webhooks.

// Observer سيئ: يخلق سلسلة من التحديثات غير الضرورية
class Order {
 constructor() {
 this.observers = [];
 }
 
 addObserver(observer) {
 this.observers.push(observer);
 }
 
 changeStatus(status) {
 this.status = status;
 this.observers.forEach(observer => observer.update(this));
 }
}

// في React Component:
const order = new Order();
order.addObserver({ update: (order) => setState({ order }) });
// كل تغيير صغير يسبب re-render كامل

// الحل الأفضل: استخدام Zustand
import { create } from 'zustand';

const useOrderStore = create((set) => ({
 order: null,
 updateOrder: (order) => set({ order }),
}));
// التحديثات تكون أكثر كفاءة وموجهة

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

الـ Factory: متى يصبح مجرد تعقيد لا لزوم له؟

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

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

# Abstract Factory معقد بلا داعٍ
class ReportFactory:
 def create_report(self, report_type):
 if report_type == "PDF":
 return PDFReport()
 elif report_type == "Excel":
 return ExcelReport()
 else:
 raise ValueError("Unknown report type")

# Simple Factory يكفي في معظم الحالات
class Report:
 def __init__(self, report_type):
 self.type = report_type
 
 def generate(self):
 if self.type == "PDF":
 return self._generate_pdf()
 elif self.type == "Excel":
 return self._generate_excel()

# استخدام مباشر بدون Factory
report = Report("PDF")
report.generate()

الـ Factory ليس سيئاً، لكنه غالباً ما يُستخدم في أماكن لا يحتاج إليها. قبل أن تستخدمه، اسأل نفسك: هل منطق الإنشاء معقد حقاً؟ هل سأحتاج إلى تغييره لاحقاً؟ إذا كانت الإجابة لا، فاستخدم الـ Constructor العادي أو الـ Simple Factory.

الأنماط التي تنقذ المشاريع حقاً: Strategy و Dependency Injection

بينما تتحدث الدورات عن الـ Singleton والـ Observer، هناك أنماط قليلة تُستخدم يومياً في المشاريع الكبيرة وتحدث فرقاً حقيقياً. الـ Strategy هو أحد هذه الأنماط. بدلاً من استخدام سلسلة من الـ if-else لتحديد سلوك معين، يمكنك فصل الخوارزميات المختلفة إلى كائنات مستقلة يمكن تبديلها في وقت التشغيل. هذا النمط مفيد جداً في الأنظمة التي تحتاج إلى دعم خيارات متعددة، مثل طرق الدفع المختلفة أو خوارزميات البحث المتنوعة.

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

// Strategy Pattern في نظام الدفع
interface PaymentStrategy {
 void pay(int amount);
}

class CreditCardPayment implements PaymentStrategy {
 @Override
 public void pay(int amount) {
 System.out.println("Paid " + amount + " via Credit Card");
 }
}

class PayPalPayment implements PaymentStrategy {
 @Override
 public void pay(int amount) {
 System.out.println("Paid " + amount + " via PayPal");
 }
}

class PaymentContext {
 private PaymentStrategy strategy;
 
 public void setPaymentStrategy(PaymentStrategy strategy) {
 this.strategy = strategy;
 }
 
 public void executePayment(int amount) {
 strategy.pay(amount);
 }
}

// استخدام:
PaymentContext c new PaymentContext();
context.setPaymentStrategy(new CreditCardPayment());
context.executePayment(100);

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

// Dependency Injection في C#
public interface IEmailService {
 void SendEmail(string to, string subject, string body);
}

public class SmtpEmailService : IEmailService {
 public void SendEmail(string to, string subject, string body) {
 // منطق إرسال البريد عبر SMTP
 }
}

public class EmailController {
 private readonly IEmailService _emailService;
 
 // الـ Dependency يتم حقنه من الخارج
 public EmailController(IEmailService emailService) {
 _emailService = emailService;
 }
 
 public void SendWelcomeEmail(string to) {
 _emailService.SendEmail(to, "Welcome", "Hello!");
 }
}

// استخدام مع حقن التبعية
var emailService = new SmtpEmailService();
var c new EmailController(emailService);

الـ Strategy والـ Dependency Injection هما مثالان على الأنماط التي تُستخدم يومياً في المشاريع الكبيرة لأنها تحل مشاكل حقيقية: المرونة وسهولة الاختبار. إذا كنت تريد تعلم نمط واحد فقط، فابدأ بهما.

متى تصبح الـ Design Patterns عبئاً بدلاً من حلاً؟

الـ Design Patterns ليست حلولاً سحرية. استخدامها في المكان الخطأ يمكن أن يجعل الكود أكثر تعقيداً وصعوبة في الصيانة. مثلاً، استخدام الـ Decorator لإضافة سلوك إلى كائنات بسيطة هو مبالغة. في مشروع لشركة لبنانية، كان لدينا نظام يعتمد على الـ Decorator لإضافة ميزات بسيطة إلى الـ User Model. النتيجة؟ كود طويل ومعقد لأداء مهمة كان يمكن حلها بسطرين من الكود العادي. الـ Decorator مفيد عندما تريد إضافة سلوك ديناميكي إلى الكائنات، مثل إضافة طبقات من الـ Logging أو الـ Caching، وليس لإضافة ميزات بسيطة.

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

• •الـ Singleton يصبح عبئاً عندما يُستخدم لإدارة الموارد المشتركة بين المستخدمين.
• •الـ Observer يصبح كارثة عندما يُستخدم لإدارة تدفق البيانات بدلاً من الإشعارات البسيطة.
• •الـ Factory يضيف تعقيداً بلا قيمة عندما يكون منطق الإنشاء بسيطاً.
• •الـ Decorator مبالغ فيه عندما يُستخدم لإضافة ميزات بسيطة بدلاً من سلوك ديناميكي.
• •الـ Command Pattern غير ضروري لإدارة طلبات HTTP البسيطة.

خلاصة المهندس: لا تكن عبداً للأنماط، كن سيدها

بعد عشر سنوات في هذا المجال، تعلمت درساً مهماً: الـ Design Patterns هي أدوات، وليست قوانين مقدسة. استخدامها في المكان الخطأ أسوأ من عدم استخدامها على الإطلاق. قبل أن تكتب سطر كود واحد، اسأل نفسك: هل هذه المشكلة تحتاج إلى نمط معين؟ أم أنني أحاول حل مشكلة غير موجودة؟

الأنماط التي أستخدمها يومياً هي الـ Strategy والـ Dependency Injection، لأنها تحل مشاكل حقيقية: المرونة وسهولة الاختبار. أما الأنماط الأخرى، فأنا أستخدمها بحذر شديد، فقط عندما تكون الحل الأمثل للمشكلة التي أواجهها. إذا كنت تريد نصيحة واحدة: لا تتعلم الأنماط لتستخدمها، تعلمها لتعرف متى لا تستخدمها.

"البرمجة الجيدة ليست عن استخدام أكبر عدد من الأنماط، بل عن كتابة أقل كمية من الكود لحل المشكلة."

— مطور مجهول في تويتر