تعتبر الفصول الدراسية ضرورية في البرمجة الموجهة للكائنات ولكن التصميم السيئ منها يمكن أن يؤدي إلى مشاكل في التعليمات البرمجية.

يسلط الفصل العاشر من الكود النظيف الضوء على أهمية الطبقات المتماسكة ذات المسؤولية الواحدة.

في هذه المقالة، سنشارك الأفكار الرئيسية ونوضح تطبيقها في JavaScript.

؟ ما هو التماسك الطبقي؟

يشير التماسك إلى مدى الارتباط الوثيق بين مسؤوليات الفصل.

يركز الفصل المتماسك على غرض واحد ولديه مسؤوليات تتلاءم معًا بشكل طبيعي.

يبقي هذا الفصل بسيطًا وسهل القراءة وسهل الصيانة.

مثال: تماسك منخفض

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  // Handles user registration
  register() {
    // Registration logic
  }

  // Sends email to user
  sendEmail(message) {
    // Email sending logic
  }

  // Logs activity of the user
  logActivity(activity) {
    console.log(`${this.name} performed: ${activity}`);
  }
}

في المثال أعلاه، لدى فئة المستخدم ثلاث مسؤوليات غير ذات صلة: تسجيل المستخدم، وإرسال رسائل البريد الإلكتروني، ونشاط التسجيل.

يفتقر هذا الفصل إلى التماسك لأنه يحاول القيام بالعديد من الأشياء في وقت واحد.

؟ مبدأ المسؤولية الفردية (SRP)

ينص مبدأ المسؤولية الفردية على أن الفصل يجب أن يكون لديه سبب واحد فقط للتغيير. وهذا يعني أن كل فصل يجب أن يركز على اهتمام واحد.

إذا كان الفصل لديه أكثر من مسؤولية واحدة، فإن التغييرات في منطقة واحدة يمكن أن تؤدي إلى تعطيل وظائف منطقة أخرى.

⚡️ إعادة البناء لـ SRP

دعونا نعيد صياغة المثال أعلاه للالتزام بـ SRP:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class UserRegistrationService {
  register(user) {
    // Registration logic
  }
}

class EmailService {
  sendEmail(user, message) {
    // Email sending logic
  }
}

class ActivityLogger {
  logActivity(user, activity) {
    console.log(`${user.name} performed: ${activity}`);
  }
}

الآن، كل فئة لديها مسؤولية واحدة:

• المستخدم: يمثل كائن المستخدم ويحتفظ بالبيانات.
• خدمة تسجيل المستخدم: تتعامل مع تسجيل المستخدم.
• خدمة البريد الإلكتروني: تتولى إرسال رسائل البريد الإلكتروني.
• ActivityLogger: يعالج تسجيل نشاط المستخدم.

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

؟ فوائد SRP والتماسك

• قابلية الصيانة: عندما يكون للفصل مسؤولية واحدة، يكون من الأسهل تحديد الأخطاء وإصلاحها. لا تحتاج إلى الخوض في المنطق غير ذي الصلة.

• قابلية التوسع: مع نمو مشروعك، فإن الالتزام بـ SRP يجعل من السهل إضافة ميزات جديدة. يمكن إضافة وظائف جديدة في فئات جديدة دون لمس الفئات الموجودة.

• قابلية الاختبار: من الأسهل اختبار الفصول ذات المسؤولية الواحدة. كل فئة لها نطاق محدود، لذلك يمكن أن تركز اختبارات الوحدة على أجزاء فردية من الوظائف.

؟ تحديد تداخل المسؤولية

للتأكد من أن فصولك متماسكة، ابحث عن المجالات التي يتم فيها الجمع بين المسؤوليات المتعددة.

في كثير من الأحيان، يبدأ الفصل الدراسي بشكل بسيط، ولكن مع إضافة الميزات، يمكن أن تتراكم واجبات إضافية.

مثال: إعادة هيكلة نظام الدفع

لنفترض أن لدينا فئة PaymentProcessor التي تتعامل مع مهام متعددة:

class PaymentProcessor {
  constructor() {
    this.paymentGateway = new PaymentGateway();
  }

  processPayment(paymentDetails) {
    // Payment processing logic
  }

  validatePaymentDetails(paymentDetails) {
    // Validation logic
  }

  logTransaction(paymentDetails) {
    console.log(`Payment processed: ${JSON.stringify(paymentDetails)}`);
  }
}

هنا، يكون PaymentProcessor مسؤولاً عن معالجة المدفوعات والتحقق من صحة التفاصيل وتسجيل المعاملات.

هذه فرصة لإعادة هيكلة المسؤوليات وتقسيمها:

class PaymentProcessor {
  constructor(paymentGateway, validator, logger) {
    this.paymentGateway = paymentGateway;
    this.validator = validator;
    this.logger = logger;
  }

  processPayment(paymentDetails) {
    if (this.validator.isValid(paymentDetails)) {
      this.paymentGateway.process(paymentDetails);
      this.logger.logTransaction(paymentDetails);
    }
  }
}

class PaymentValidator {
  isValid(paymentDetails) {
    // Validation logic
    return true; // Simplified for example
  }
}

class PaymentLogger {
  logTransaction(paymentDetails) {
    console.log(`Payment processed: ${JSON.stringify(paymentDetails)}`);
  }
}

الآن، تتحمل فئة PaymentProcessor مسؤولية واحدة: معالجة المدفوعات.

تم نقل التحقق من الصحة والتسجيل إلى فئات منفصلة (PaymentValidator وPaymentLogger).

⚡️الخلاصة

يضمن تصميم الفصول الدراسية بشكل متماسك والالتزام بمبدأ المسؤولية الفردية أن تظل قاعدة التعليمات البرمجية الخاصة بك مرنة وقابلة للصيانة وسهلة الفهم.

من خلال تقسيم المسؤوليات إلى فئات منفصلة ومركزة، يمكنك تقليل تعقيد المكونات الفردية وجعل نظامك أكثر قوة.

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

كما يوضح كتاب الكود النظيف، فإن كتابة الفصول النظيفة لا تتعلق فقط بتنظيم التعليمات البرمجية، بل تتعلق بإنشاء نظام يمكن أن يتطور دون أن يصبح كابوسًا للمحافظة عليه.

برمجة سعيدة!