DevGuide 🇵🇸

مفهوم الـ Dependency Inversion Principle 💡
.
.
فيه مبدأ من مبادئ SOLID بيغيّر طريقة تفكيرك في تصميم الكود بشكل كبير جدًا...
مبدأ أول ما تفهمه كويس وتطبّقه صح، هتحس إن المشروع بقى modular أكتر، والـ testing بقى أسهل، والـ bugs بقت قليلة إلى حد ما...

تعال ندردش شوية عن مبدأ الـ Dependency Inversion...

———

📌 يعني إيه Dependency Inversion Principle؟

المبدأ ده بيقول:

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

و

"Abstractions should not depend on details. Details should depend on abstractions."

يعني لما تيجي تبني جزء كبير من السيستم (زي مثلاً order service في تطبيق تجارة إلكترونية)، المفروض ميكنش الـ high-level logic (زي إزاي الـ order بيتم) بيعتمد مباشرة على الـ details زي مثلا API معين أو database معينة أو class بتبعت إيميلات.

بدل كده، المفروض يكون بيعتمد على abstraction (interface أو contract)، بحيث التفاصيل دي تقدر تتغير بسهولة بعد كده من غير ما تغيّر في الـ business logic نفسه.

———

📦 مثال بسيط:

[ كل الأكواد في التعليقات 👇 ]

class EmailService {
  sendEmail(to: string, body: string) {
    // logic to send email
  }
}

class OrderService {
  private emailService = new EmailService();

  placeOrder(orderData: any) {
    // logic to place order
    this.emailService.sendEmail(orderData.customerEmail, "Order placed!");
  }
}

كده الـ OrderService معتمد بشكل مباشر على الـ EmailService.

لو حبيت تغير وسيلة إرسال الإيميل أو تبعتها عبر SMS أو push notification، هتضطر تغيّر في الكود بتاع OrderService نفسه… وده ضد مبدأ open/closed principle كمان.

———

✅ الحل؟

interface Notifier {
  notify(to: string, message: string): void;
}

class EmailService implements Notifier {
  notify(to: string, message: string) {
    // send email
  }
}

class SMSService implements Notifier {
  notify(to: string, message: string) {
    // send sms
  }
}

class OrderService {
  constructor(private notifier: Notifier) {}

  placeOrder(orderData: any) {
    // logic to place order
    this.notifier.notify(orderData.customerContact, "Order placed!");
  }
}

كده الـ OrderService ميعرفش أي حاجة عن الـ implementation بتاع الـ notifier، سواء كان email أو sms.

هو بس بيتعامل مع abstraction (interface اسمها Notifier).
وبالتالي تقدر تغير الـ implementation في أي وقت من غير ما تلمس الـ OrderService.

———

💡 إزاي ده هيفرق معاك؟

- الكود بتاعك بقى loosely coupled.
- بقى modular وأسهل في التعديل والصيانة.
- الـ testing بقى أبسط لأنك تقدر تعمل mock لـ Notifier بسهولة.
- بقيت تقدر تبدّل الـ implementation من غير ما تعمل refactor تقيل.

———

الـ Dependency Inversion بيخليك دايمًا تفكر في dependencies على إنها شيء ممكن يتغير… فبدل ما تبني عليها بشكل مباشر، استخدم abstraction تفصل به بين high-level logic و low-level details.

———

وفقكم الله لكل خير 🌿

❤10

www.tgoop.com/the_developer_guide/5492

1.28K viewsAug 1 at 18:00

مفهوم الـ Dependency Inversion Principle 💡
.
.
فيه مبدأ من مبادئ SOLID بيغيّر طريقة تفكيرك في تصميم الكود بشكل كبير جدًا...
مبدأ أول ما تفهمه كويس وتطبّقه صح، هتحس إن المشروع بقى modular أكتر، والـ testing بقى أسهل، والـ bugs بقت قليلة إلى حد ما...

تعال ندردش شوية عن مبدأ الـ Dependency Inversion...

———

📌 يعني إيه Dependency Inversion Principle؟

المبدأ ده بيقول:

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

و

"Abstractions should not depend on details. Details should depend on abstractions."

يعني لما تيجي تبني جزء كبير من السيستم (زي مثلاً order service في تطبيق تجارة إلكترونية)، المفروض ميكنش الـ high-level logic (زي إزاي الـ order بيتم) بيعتمد مباشرة على الـ details زي مثلا API معين أو database معينة أو class بتبعت إيميلات.

بدل كده، المفروض يكون بيعتمد على abstraction (interface أو contract)، بحيث التفاصيل دي تقدر تتغير بسهولة بعد كده من غير ما تغيّر في الـ business logic نفسه.

———

📦 مثال بسيط:

class EmailService {
  sendEmail(to: string, body: string) {
    // logic to send email
  }
}

class OrderService {
  private emailService = new EmailService();

  placeOrder(orderData: any) {
    // logic to place order
    this.emailService.sendEmail(orderData.customerEmail, "Order placed!");
  }
}

✅ الحل؟

interface Notifier {
  notify(to: string, message: string): void;
}

class EmailService implements Notifier {
  notify(to: string, message: string) {
    // send email
  }
}

class SMSService implements Notifier {
  notify(to: string, message: string) {
    // send sms
  }
}

class OrderService {
  constructor(private notifier: Notifier) {}

  placeOrder(orderData: any) {
    // logic to place order
    this.notifier.notify(orderData.customerContact, "Order placed!");
  }
}

💡 إزاي ده هيفرق معاك؟

BY DevGuide 🇵🇸