Dependency Injection

Dependency Injection هي تقنية تصميم برمجيات تستخدم لجعل الكود الموجه للكائنات أكثر مرونة وقابلة للاختبار والصيانة. وتسمح لـ class بأن يستقبل الكائنات التي يحتاجها من الخارج بدلاً من إنشائها داخليًا.

في البرمجة كائنية التوجه، التبعية هي أي كائن أو خدمة أو مكون يحتاجه class آخر لأداء عمله. يساعد Dependency Injection على إدارة هذه التبعيات بطريقة نظيفة ويقلل tight coupling بين classes.

مقدمة

في المقالات السابقة من سلسلة OOP وDesign Patterns، ناقشنا مفاهيم مهمة مثل classes، والكائنات، encapsulation، inheritance، polymorphism، abstraction، interfaces، وأنماط التصميم، وRepository Pattern، وStrategy Pattern، وObserver Pattern، وCommand Pattern.

يرتبط Dependency Injection بقوة بالعديد من هذه المفاهيم. إنه يعمل بشكل جيد بشكل خاص مع interfaces، وabstraction، وpolymorphism، وrepositories، والخدمات، والهندسة المعمارية النظيفة.

العديد من الأطر الحديثة مثل Laravel وSymfony وSpring وNestJS وASP.NET تستخدم Dependency Injection بشكل كبير. يساعد فهمها المطورين على كتابة كود أكثر وضوحًا وفهم كيفية إدارة أطر العمل الخلفية الاحترافية للخدمات.

ما هو Dependency Injection؟

Dependency Injection هي تقنية حيث يتلقى class الكائنات التي يعتمد عليها من مصدر خارجي بدلاً من إنشائها بنفسه.

بعبارات بسيطة، بدلًا من قول class "سأقوم بإنشاء ما أحتاج إليه"، يقول class "أعطني ما أحتاج إليه".

على سبيل المثال، قد تحتاج خدمة OrderService إلى خدمة PaymentService وEmailService. بدون Dependency Injection، تقوم OrderService بإنشاء هذه الخدمات داخل نفسها. باستخدام Dependency Injection، يتم تمرير هذه الخدمات إلى OrderService من الخارج.

ما هي التبعية؟

التبعية هي أي كائن أو خدمة يحتاج class آخر إلى استخدامها. إذا لم يتمكن class من إكمال مهمته بدون class آخر، فإن class الآخر يعد تبعية.

على سبيل المثال:

• قد تعتمد خدمة المستخدم على UserRepository.
• قد تعتمد خدمة الطلب على بوابة الدفع.
• قد تعتمد خدمة التقارير على PdfExporter.
• قد تعتمد خدمة الإشعارات على EmailSender.
• قد تعتمد خدمة CheckoutService على الخصمStrategy.

يعطي Dependency Injection هذه التبعيات إلى class بدلاً من إجبار class على إنشائها مباشرةً.

مشكلة بدون Dependency Injection

بدون Dependency Injection، قد يقوم class بإنشاء تبعياته داخليًا باستخدام الكلمة الأساسية الجديدة.

class OrderService
{
    private PaymentService $paymentService;
    private EmailService $emailService;

    public function __construct()
    {
        $this->paymentService = new PaymentService();
        $this->emailService = new EmailService();
    }

    public function placeOrder(Order $order): void
    {
        $this->paymentService->charge($order);
        $this->emailService->sendConfirmation($order);
    }
}

هذا الكود يعمل، لكن به مشكلة في التصميم. ترتبط OrderService ارتباطًا وثيقًا بخدمة PaymentService وEmailService. فهو يقرر استخدام concrete classes وكيفية إنشائها.

إذا احتاج التطبيق لاحقًا إلى استخدام موفر دفع مختلف، أو خدمة دفع زائفة للاختبار، أو مرسل بريد إلكتروني مختلف، فيجب تعديل OrderService class.

الحل مع Dependency Injection

باستخدام Dependency Injection، يتم تمرير التبعيات إلى class من الخارج.

class OrderService
{
    public function __construct(
        private PaymentService $paymentService,
        private EmailService $emailService
    ) {
    }

    public function placeOrder(Order $order): void
    {
        $this->paymentService->charge($order);
        $this->emailService->sendConfirmation($order);
    }
}

الآن لا تقوم OrderService بإنشاء التبعيات بنفسها. ويستقبلهم من خلال constructor. وهذا يجعل تكوين class أسهل واختباره وتغييره أسهل.

لماذا يعد Dependency Injection مهمًا

يعد Dependency Injection مهمًا لأنه يقلل من tight coupling بين classes. يجب أن يركز class على مسؤوليته الرئيسية، وليس على إنشاء وتكوين جميع الخدمات التي يحتاجها.

عندما يتم حقن التبعيات، يصبح class أكثر مرونة. يمكن تمرير تطبيقات مختلفة اعتمادًا على البيئة أو التكوين أو حالة الاختبار.

وهذا مهم بشكل خاص في التطبيقات الكبيرة حيث قد تحتوي الخدمات على العديد من التبعيات وحيث يجب اختبار الكود بشكل موثوق.

Dependency Injection وInterfaces

يصبح Dependency Injection أكثر قوة عند دمجه مع interfaces. بدلاً من الاعتماد على concrete class، يمكن أن تعتمد الخدمة على interface.

على سبيل المثال، بدلاً من الاعتماد مباشرة على StripePaymentGateway، يمكن أن تعتمد CheckoutService على PaymentGatewayInterface.

interface PaymentGatewayInterface
{
    public function charge(Order $order): bool;
}

class StripePaymentGateway implements PaymentGatewayInterface
{
    public function charge(Order $order): bool
    {
        // Charge using Stripe
        return true;
    }
}

class PayPalPaymentGateway implements PaymentGatewayInterface
{
    public function charge(Order $order): bool
    {
        // Charge using PayPal
        return true;
    }
}

الآن يمكن للتطبيق إدخال أي بوابة دفع تنفذ نفس interface.

مثال على Interface القائم على Dependency Injection

class CheckoutService
{
    public function __construct(
        private PaymentGatewayInterface $paymentGateway
    ) {
    }

    public function checkout(Order $order): bool
    {
        return $this->paymentGateway->charge($order);
    }
}

لا تعرف خدمة CheckoutService ما إذا كانت تتم معالجة الدفع بواسطة Stripe أو PayPal أو التحويل البنكي أو موفر آخر. يعتمد ذلك فقط على PaymentGatewayInterface.

وهذا يجعل النظام أسهل في التوسع. يمكن إضافة مزود دفع جديد دون تغيير خدمة CheckoutService.

أنواع Dependency Injection

هناك عدة طرق لإدخال التبعيات في class. الأنواع الأكثر شيوعًا هي:

• حقن Constructor: يتم تمرير التبعيات عبر constructor.
• حقن الواضع: يتم تمرير التبعيات من خلال طرق الضبط.
• حقن الطريقة: يتم تمرير التبعيات مباشرة إلى الطريقة التي تحتاجها.

كل نوع له حالات استخدام مختلفة، ولكن حقن constructor عادة ما يكون الأسلوب الأكثر شيوعًا والموصى به للتبعيات المطلوبة.

حقن Constructor

حقن Constructor يعني تمرير التبعيات عبر class constructor. هذا هو الشكل الأكثر شيوعًا لـ Dependency Injection.

class ReportService
{
    public function __construct(
        private ReportRepository $repository,
        private PdfExporter $exporter
    ) {
    }

    public function generate(int $reportId): string
    {
        $report = $this->repository->findById($reportId);

        return $this->exporter->export($report);
    }
}

يعد حقن Constructor مفيدًا عند الحاجة إلى التبعية حتى يعمل class. يجعل التبعية واضحة ويضمن إنشاء الكائن في حالة صالحة.

حقن سيتر

يعني حقن Setter تمرير التبعية من خلال طريقة setter بعد إنشاء الكائن.

class NewsletterService
{
    private ?LoggerInterface $logger = null;

    public function setLogger(LoggerInterface $logger): void
    {
        $this->logger = $logger;
    }

    public function send(string $email): void
    {
        // Send newsletter

        if ($this->logger) {
            $this->logger->info('Newsletter sent.');
        }
    }
}

يمكن أن يكون حقن Setter مفيدًا للتبعيات الاختيارية. ومع ذلك، يجب استخدامه بعناية لأن الكائن قد يكون موجودًا دون تعيين التبعية.

طريقة الحقن

حقن الطريقة يعني تمرير التبعية مباشرة إلى الطريقة التي تحتاجها.

class FileImportService
{
    public function import(string $filePath, FileParserInterface $parser): array
    {
        return $parser->parse($filePath);
    }
}

يكون حقن الطريقة مفيدًا عندما تكون التبعية مطلوبة فقط لطريقة واحدة محددة ولا يلزم تخزينها كجزء من حالة الكائن.

Dependency Injection والاختبار

واحدة من أكبر فوائد Dependency Injection هي سهولة الاختبار. عندما يتلقى class تبعيات من الخارج، يمكن للاختبارات تمرير تبعيات وهمية أو وهمية بدلاً من الخدمات الحقيقية.

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

class FakePaymentGateway implements PaymentGatewayInterface
{
    public function charge(Order $order): bool
    {
        return true;
    }
}

يمكن للاختبار الآن استخدام التنفيذ المزيف:

$checkout = new CheckoutService(new FakePaymentGateway());

$result = $checkout->checkout($order);

وهذا يجعل الاختبارات أسرع وأكثر أمانًا وأكثر قابلية للتنبؤ بها.

Dependency Injection وLoose Coupling

Loose coupling يعني أن classes لا تعتمد بشكل كبير على تطبيقات concrete محددة. يدعم Dependency Injection loose coupling لأنه يتم توفير التبعيات من الخارج.

عندما يعتمد class على interface، فيمكنه العمل مع العديد من التطبيقات المختلفة. وهذا يقلل من تأثير التغيير.

على سبيل المثال، لا يتطلب التغيير من StripePaymentGateway إلى PayPalPaymentGateway تغيير CheckoutService إذا قام كل من classes بتطبيق PaymentGatewayInterface.

مبادئ Dependency Injection وSOLID

يرتبط Dependency Injection ارتباطًا وثيقًا بمبادئ SOLID، وخاصة مبدأ انعكاس التبعية.

ينص مبدأ انعكاس التبعية على أن الوحدات عالية المستوى لا ينبغي أن تعتمد على الوحدات ذات المستوى المنخفض. يجب أن يعتمد كلاهما على abstractions. وتقول أيضًا أن abstractions يجب ألا تعتمد على التفاصيل. يجب أن تعتمد التفاصيل على abstractions.

يساعد Dependency Injection في تطبيق هذا المبدأ من خلال السماح للخدمات عالية المستوى بالاعتماد على interfaces بدلاً من concrete classes.

Dependency Injection مقابل انعكاس التبعية

يرتبط Dependency Injection وDependency Inversion، لكنهما ليسا متماثلين.

انعكاس التبعية هو مبدأ التصميم. تقول أن الكود يجب أن تعتمد على abstractions بدلاً من تطبيقات concrete.

Dependency Injection هي تقنية تستخدم لتوفير التبعيات إلى class من الخارج. إنها إحدى الطرق العملية لتطبيق عكس التبعية.

بعبارات بسيطة، عكس التبعية هو الفكرة، وDependency Injection هي إحدى الطرق لتنفيذ هذه الفكرة.

Dependency Injection Container

Dependency Injection container هي أداة تقوم تلقائيًا بإنشاء الكائنات وإدراج تبعياتها. بدلاً من إنشاء كل خدمة يدويًا وتمرير التبعيات، يقوم container بحلها تلقائيًا.

تستخدم الأطر الحديثة containers بكثافة. يعرف container كيفية بناء الخدمات، وأي تطبيق يجب استخدامه لـ interface، وكيف يجب ربط التبعيات معًا.

على سبيل المثال، إذا كانت وحدة التحكم تحتاج إلى UserService، ويحتاج UserService إلى UserRepository، فيمكن لـ container إنشاء الرسم البياني الكامل للكائن تلقائيًا.

دليل Dependency Injection مثال

بدون container، يمكن توصيل التبعيات يدويًا:

$repository = new UserRepository();
$emailService = new EmailService();
$userService = new UserService($repository, $emailService);

وهذا واضح في التطبيقات الصغيرة، لكنه يصبح أكثر صعوبة عندما تعتمد العديد من الخدمات على خدمات أخرى.

يقوم DI container بأتمتة هذه العملية.

Dependency Injection في Laravel

يحتوي Laravel على service container القوي الذي يدير Dependency Injection. يمكن لـ Laravel إدخال التبعيات تلقائيًا في وحدات التحكم والخدمات والوظائف وlisteners والبرامج الوسيطة وcommands.

على سبيل المثال، يمكن لوحدة التحكم Laravel تلقي خدمة من خلال constructor:

class UserController
{
    public function __construct(
        private UserService $userService
    ) {
    }

    public function store(Request $request)
    {
        return $this->userService->create($request->all());
    }
}

يقوم Laravel بحل خدمة UserService تلقائيًا من service container.

ربط Interfaces في Laravel

عندما يعتمد class على interface، يحتاج Laravel إلى معرفة التطبيق الذي يجب استخدامه. ويتم ذلك من خلال الربط.

use App\Contracts\PaymentGatewayInterface;
use App\Services\StripePaymentGateway;

public function register(): void
{
    $this->app->bind(
        PaymentGatewayInterface::class,
        StripePaymentGateway::class
    );
}

بعد هذا الربط، فإن أي class يتطلب PaymentGatewayInterface سوف يتلقى StripePaymentGateway ما لم يتم تغيير الربط.

Laravel تجليد مفرد

يمكن لـ Laravel أيضًا ربط الخدمة كخدمة مفردة، مما يعني إعادة استخدام نفس المثيل.

$this->app->singleton(
    SettingsRepository::class,
    DatabaseSettingsRepository::class
);

يوفر هذا سلوك مثيل مشترك من خلال service container دون إجبار class نفسه على تنفيذ Singleton Pattern يدويًا.

Dependency Injection في Symfony

يستخدم Symfony أيضًا Dependency Injection container. يتم تعريف الخدمات وتكوينها، ويقوم Symfony بإدخال التبعيات تلقائيًا من خلال constructors أو تكوين الخدمة.

على سبيل المثال، قد تتلقى خدمة Symfony repository والمسجل من خلال constructor:

class ReportService
{
    public function __construct(
        private ReportRepository $repository,
        private LoggerInterface $logger
    ) {
    }
}

يمكن لـ Symfony توصيل هذه التبعيات تلقائيًا عند تسجيل الخدمات بشكل صحيح.

التوصيل التلقائي

يعد التوصيل التلقائي ميزة حيث يكتشف إطار العمل تلقائيًا التبعيات من تلميحات الكتابة ويدخل الخدمات الصحيحة.

على سبيل المثال، إذا كان constructor يتطلب LoggerInterface، فيمكن أن يوفر container خدمة المسجل التي تم تكوينها تلقائيًا.

يعمل التوصيل التلقائي على تقليل التكوين اليدوي ويجعل استخدام Dependency Injection أسهل، خاصة في أطر عمل PHP الحديثة.

Dependency Injection وDesign Patterns

يعمل Dependency Injection بشكل جيد مع العديد من أنماط التصميم. يتم استخدامه غالبًا مع Repository Pattern، وStrategy Pattern، وAdapter Pattern، وDecorator Pattern، وCommand Pattern، وObserver Pattern.

على سبيل المثال، قد تتلقى إحدى الخدمات repository من خلال dependency injection. قد تتلقى خدمة الخروج دفعة strategy. قد تتلقى خدمة الإعلام adapter لموفر SMS خارجي. قد يتلقى command handler repositories والخدمات.

يجعل Dependency Injection هذه الأنماط أكثر مرونة لأنه يمكن استبدال التبعيات دون تغيير class الذي يستخدمها.

Dependency Injection وRepository Pattern

يستخدم Repository Pattern غالبًا Dependency Injection. يمكن أن تعتمد الخدمة على تطبيق repository interface بدلاً من تطبيق concrete repository.

class UserService
{
    public function __construct(
        private UserRepositoryInterface $users
    ) {
    }
}

وهذا يجعل الخدمة مستقلة عن Eloquent أو Doctrine أو PDO أو أي مصدر بيانات محدد.

Dependency Injection وStrategy Pattern

يعمل Strategy Pattern أيضًا بشكل طبيعي مع Dependency Injection. يمكن أن يتلقى السياق class strategy من خلال constructor.

class DiscountService
{
    public function __construct(
        private DiscountStrategy $strategy
    ) {
    }

    public function calculate(float $total): float
    {
        return $this->strategy->calculate($total);
    }
}

يمكن تغيير strategy دون تعديل خدمة الخصم.

Dependency Injection وDecorator Pattern

يستخدم Decorator Pattern غالبًا Dependency Injection لأن decorator يلتف على كائن آخر يقوم بتنفيذ نفس interface.

class CachedProductRepository implements ProductRepositoryInterface
{
    public function __construct(
        private ProductRepositoryInterface $repository,
        private CacheInterface $cache
    ) {
    }
}

يتم إدخال خدمة repository وذاكرة التخزين المؤقت المزخرفة من الخارج، مما يجعل decorator مرنًا وقابلاً للاختبار.

Dependency Injection مقابل محدد مواقع الخدمة

محدد موقع الخدمة هو نمط آخر حيث يسأل class كائنًا مركزيًا أو container عن تبعياته. على سبيل المثال، قد يقوم class باستدعاء التطبيق (PaymentGateway::class) داخليًا.

عادةً ما يتم تفضيل Dependency Injection لأن التبعيات تكون مرئية في constructor أو توقيع الطريقة. وهذا يجعل class أسهل في الفهم والاختبار.

يمكن لمحدد خدمة الخدمة إخفاء التبعيات. قد يبدو أن class لا يحتوي على أي تبعيات، ولكنه يجلب العديد من الخدمات داخليًا من container. وهذا يجعل من الصعب تحليل الكود.

مثال سيء: التبعيات المخفية

class CheckoutService
{
    public function checkout(Order $order): bool
    {
        $paymentGateway = app(PaymentGatewayInterface::class);

        return $paymentGateway->charge($order);
    }
}

هذا يخفي التبعية داخل الطريقة. من الأفضل إدخال بوابة الدفع من خلال constructor.

مثال أفضل: التبعيات الصريحة

class CheckoutService
{
    public function __construct(
        private PaymentGatewayInterface $paymentGateway
    ) {
    }

    public function checkout(Order $order): bool
    {
        return $this->paymentGateway->charge($order);
    }
}

الآن أصبحت التبعية واضحة وأسهل في الاستبدال في الاختبارات.

فوائد Dependency Injection

يوفر Dependency Injection العديد من الفوائد في تصميم البرامج الموجهة للكائنات.

تشمل الفوائد الرئيسية ما يلي:

• يقلل tight coupling بين classes.
• يجعل التبعيات واضحة.
• يحسن قابلية الاختبار باستخدام التبعيات المزيفة أو الوهمية.
• يدعم التصميم المستند إلى interface.
• يجعل الكود أسهل للتوسيع والصيانة.
• يعمل بشكل جيد مع مبادئ SOLID.
• يسمح باستبدال أسهل للتطبيقات.
• يحسن تنظيم المشروع في التطبيقات الكبيرة.

هذه الفوائد تجعل Dependency Injection أحد أهم التقنيات في تطوير البرمجيات الاحترافية.

عيوب Dependency Injection

يمكن أن يكون لـ Dependency Injection أيضًا عيوب إذا تم استخدامه بشكل غير صحيح. قد يضيف المزيد من classes وinterfaces والتكوين إلى المشروع.

بالنسبة للتطبيقات الصغيرة، قد يكون إنشاء الكائنات يدويًا أسهل. في التطبيقات الكبيرة، عادةً ما يكون Dependency Injection يستحق البنية.

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

Constructor الإفراط في الحقن

يحدث الإفراط في حقن Constructor عندما يتطلب class الكثير من التبعيات في constructor.

class ReportService
{
    public function __construct(
        private A $a,
        private B $b,
        private C $c,
        private D $d,
        private E $e,
        private F $f
    ) {
    }
}

قد يشير هذا إلى أن ReportService تقوم بالكثير من العمل. الحل ليس إخفاء التبعيات باستخدام محدد موقع الخدمة. الحل الأفضل هو مراجعة مسؤوليات class وتقسيم المنطق إذا لزم الأمر.

متى يتم استخدام Dependency Injection

استخدم Dependency Injection عندما يعتمد class على الخدمات، أو repositories، أو APIs خارجية، أو الاستراتيجيات، أو adapter، أو أدوات قطع الأشجار، أو الكائنات الأخرى التي قد تتغير أو تحتاج إلى اختبار.

يكون Dependency Injection مفيدًا عندما:

• يعتمد class على خدمة أو كائن آخر.
• تريد اختبار class باستخدام تبعيات وهمية.
• تريد الاعتماد على interfaces بدلاً من concrete classes.
• قد يتغير التنفيذ في المستقبل.
• يستخدم المشروع إطار عمل service container.
• تريد تقليل tight coupling.
• تريد أن تكون التبعيات مرئية وصريحة.

إذا كانت هذه الشروط موجودة، فإن Dependency Injection عادةً ما يكون اختيارًا قويًا للتصميم.

متى لا تستخدم Dependency Injection

Dependency Injection ليس ضروريًا دائمًا لكل كائن صغير. قد لا تحتاج كائنات القيمة البسيطة وDTOs وentities وكائنات المرافق الصغيرة إلى خدمات محقونة.

تجنب Dependency Injection غير الضرورية عندما:

• لا يحتوي class على أي تبعيات خارجية حقيقية.
• الكائن عبارة عن بيانات بسيطة container أو كائن قيمة.
• الإنشاء اليدوي أبسط وأكثر وضوحًا.
• لن يتم استبدال التبعية أو الاستهزاء بها أبدًا.
• يضيف النمط تعقيدًا دون تحسين التصميم.

التصميم الجيد يجب أن يكون عملياً. يجب أن يجعل Dependency Injection الكود أكثر وضوحًا وليس أكثر تعقيدًا.

الأخطاء الشائعة في Dependency Injection

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

خطأ آخر هو الاعتماد على concrete classes عندما يكون interface أفضل. إذا كان التنفيذ قد يتغير، فيمكن لـ interface تحسين المرونة.

الخطأ الثالث هو استخدام service container مباشرة داخل العمل classes. وهذا يخفي التبعيات ويجعل الاختبار أكثر صعوبة.

الخطأ الرابع هو إنشاء interfaces لكل class بدون سبب حقيقي. تكون Interfaces مفيدة عند وجود تطبيقات متعددة أو عند اختبار المادة وفصلها.

أفضل الممارسات لـ Dependency Injection

لاستخدام Dependency Injection بشكل فعال، يجب على المطورين الحفاظ على التبعيات واضحة وذات معنى ومركزة.

تتضمن أفضل الممارسات المفيدة ما يلي:

• تفضل حقن constructor للتبعيات المطلوبة.
• استخدم interfaces عند احتمال وجود تطبيقات متعددة.
• احتفظ بالتبعيات بشكل واضح في constructor.
• تجنب استخدام service container كمحدد موقع خدمة مخفي.
• انتبه إلى الإفراط في حقن constructor كتحذير للتصميم.
• استخدم حقن الضبط فقط للتبعيات الاختيارية.
• استخدم حقن الطريقة للتبعيات التي تحتاجها طريقة واحدة فقط.
• حافظ على تركيز classes على مسؤولية واحدة.
• استخدم إطار العمل containers لأسلاك الخدمة في التطبيقات الكبيرة.

تساعد هذه الممارسات في الحفاظ على Dependency Injection نظيفًا ومفيدًا.

قائمة مرجعية عملية قبل استخدام Dependency Injection

قبل استخدام Dependency Injection، يمكن للمطورين طرح هذه الأسئلة:

• هل يعتمد class هذا على خدمة أو كائن آخر؟
• هل سأحتاج إلى استبدال هذه التبعية في الاختبارات؟
• هل يمكن أن يكون لهذه التبعية تطبيقات متعددة؟
• هل يجب أن يعرف class كيفية إنشاء التبعية؟
• هل سيؤدي Dependency Injection إلى تقليل الاقتران؟
• هل التبعية مطلوبة أم اختيارية؟
• هل يُظهر constructor الكثير من المسؤوليات؟

إذا كانت الإجابة بنعم على العديد من هذه الأسئلة، فمن المحتمل أن يكون Dependency Injection اختيارًا جيدًا للتصميم.

الاستنتاج

Dependency Injection هي تقنية قوية في البرمجة كائنية التوجه تسمح لـ classes بتلقي تبعياتها من الخارج بدلاً من إنشائها داخليًا. فهو يقلل من tight coupling، ويجعل التبعيات واضحة، ويحسن قابلية الاختبار، ويدعم بنية البرامج النظيفة.

يعمل Dependency Injection بشكل جيد مع interfaces، وrepositories، والاستراتيجيات، وadapters، وdecorators، وcommand handlers، وطبقات الخدمة. إنه مفهوم أساسي في الأطر الحديثة مثل Laravel وSymfony.

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