0Pricing
Clean Architecture & Design Patterns in Practice · درس

إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق

عمّق إلمامك بأول مبدأين من مبادئ SOLID، وتعلّم تحديد حدود المسؤوليات وتوسيع السلوك من دون تعديل الشيفرة الموجودة.

إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق درس مجاني في Clean Architecture & Design Patterns in Practice على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Clean Architecture & Design Patterns in Practice، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Clean Architecture & Design Patterns in Practice 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

Back to the Foundations

You have explored Dependency Inversion and Interface Segregation. This lesson masters the remaining pair:

  • Single Responsibility Principle (SRP)
  • Open-Closed Principle (OCP)

These two drive most everyday refactoring decisions.

SRP Defined Precisely

SRP says a class should have one reason to change. A reason to change maps to a single actor or stakeholder.

If billing rules and report formatting can change independently, they belong in different classes.

Spotting an SRP Violation

This class mixes calculation, persistence, and presentation.

class Employee {
    double calculatePay() { return 0; }
    void save() { /* DB code */ }
    String reportHtml() { return "<html>"; }
}

Refactoring Toward SRP

Split responsibilities so each changes for one reason.

class PayCalculator { double calculate(Employee e) { return 0; } }
class EmployeeRepository { void save(Employee e) {} }
class EmployeeReporter { String html(Employee e) { return "<html>"; } }

The Cohesion Payoff

After the split, each class is more cohesive: everything inside relates to one job.

Changes are localized, tests are focused, and accidental coupling between unrelated concerns disappears.

OCP Defined

The Open-Closed Principle: software entities should be open for extension but closed for modification.

You should be able to add new behavior by writing new code, not editing existing, tested code.

An OCP Violation

Adding a shape forces editing this method every time.

double area(Shape s) {
    if (s.type.equals("circle")) return 3.14 * s.r * s.r;
    else if (s.type.equals("square")) return s.side * s.side;
    return 0;
}

Closing It With Polymorphism

Make each shape compute its own area. New shapes require no edits to existing code.

interface Shape { double area(); }
class Circle implements Shape {
    double r;
    public double area() { return 3.14 * r * r; }
}
class Square implements Shape {
    double side;
    public double area() { return side * side; }
}

OCP Through Strategy and Plugins

Common OCP-enabling techniques:

  • Polymorphism over conditionals.
  • The Strategy pattern to inject varying behavior.
  • Plugin or registry mechanisms for adding handlers.

All let you extend by adding, not editing.

How SRP and OCP Reinforce Each Other

A class with a single responsibility is much easier to keep closed for modification, because there is only one axis of change.

When you cleanly separate responsibilities, extension points emerge naturally.

Pragmatic Limits

Do not over-apply. Premature abstraction for variation that never comes adds needless complexity.

Apply OCP at the points your domain actually varies; let the rest stay simple until change demands it.

Quick Check

Test your grasp of SRP and OCP.

Recap

You mastered the first two SOLID principles.

  • SRP: one reason to change per class.
  • OCP: extend by adding, not editing.
  • They reinforce each other and guide most refactorings, applied where variation truly exists.

الأسئلة الشائعة

هل درس «إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق» مجاني؟

نعم — نص درس «إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Clean Architecture & Design Patterns in Practice، انتقل إلى CoddyKit PRO. تتضمن دورة Clean Architecture & Design Patterns in Practice 4 دروس في المجموع.

ماذا ستتعلم في «إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق»؟

عمّق إلمامك بأول مبدأين من مبادئ SOLID، وتعلّم تحديد حدود المسؤوليات وتوسيع السلوك من دون تعديل الشيفرة الموجودة. تتمرن على Clean Architecture & Design Patterns in Practice مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Clean Architecture & Design Patterns in Practice؟

لا تُشترط خبرة سابقة. Clean Architecture & Design Patterns in Practice على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Clean Architecture & Design Patterns in Practice هذا؟

نعم. كل درس في Clean Architecture & Design Patterns in Practice يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. تعمّق في Dependency Inversion
  2. تطبيق Interface Segregation
  3. إعادة الهيكلة باستخدام أنماط التصميم
  4. إتقان مبدأَي المسؤولية الواحدة والانفتاح-الإغلاق
← العودة إلى Clean Architecture & Design Patterns in Practice