بمشروعي ذو الحجم المتوسط، قررت استخدام الـ static classes للمخازن (repositories) والخدمات (services) وغيرها، ولقد عمل هذا بشكل جيد للغاية، حتى لو كان معظم المبرمجين يتوقعون العكس. كانت قاعدة الشفرة الخاصة بي مضغوطة للغاية ونظيفة وسهلة الفهم. ثم قررت أن أعيد كتابة كل شيء واستخدام تقنية IoC (Inversion of Control) ولكني كنت مصدومًا تمامًا. يتوجب علي تهيئة العديد من التبعيات يدويًا في كل فئة وتحكم، وإضافة المزيد من المشاريع للواجهات وهلم جرا. حقًا، لا أرى أي فوائد في مشروعي ويبدو أنه يسبب المزيد من المشاكل مما يحله. لقد وجدت العديد من العيوب في IoC/DI:
- حجم شفرة أكبر بكثير.
- شفرة تشبه الـ ravioli بدلاً من الـ spaghetti.
- أداء أبطأ، حيث يتعين تهيئة جميع التبعيات في المُنشئ (constructor) حتى إذا كانت الطريقة التي أريد استدعاءها تحتوي على تبعية واحدة فقط.
- أصعب فهماً عندما لا يتم استخدام بيئة تطوير مُتكاملة (IDE).
- بعض الأخطاء تنتقل إلى وقت التشغيل.
- إضافة تبعية إضافية (إطار DI ذاته).
- يجب على الأشخاص الجدد تعلم DI أولاً للعمل به.
- الكثير من الشفرة المتكررة، وهو أمر سيء للأشخاص الإبداعيين (على سبيل المثال، نسخ الفئات من المنشئ إلى الخصائص).
نحن لا نقوم بفحص الشفرة بأكملها، ولكننا نختبر بعض الطرق ونستخدم قاعدة بيانات حقيقية. لذا، هل يجب تجنب Dependency Injection عندما لا يكون هناك حاجة لاستخدام الـ mocking في الاختبار؟
المزيد من المعلومات
عندما يتعلق الأمر بتقنيات البرمجة، فإن الخيار بين استخدام Dependency Injection (DI) وعدم استخدامها قد يكون محيرًا للكثيرين، خاصةً مع وجود حجج مقنعة لكل جانب. لكن دعونا نستكشف هذا الأمر بعمق.
أولًا وقبل كل شيء، دعونا نلقي نظرة على فوائد استخدام Dependency Injection:
-
إدارة الاعتماديات: باستخدام DI، يصبح من السهل استبدال تطبيقات الاعتماديات بديلة خلال تطوير التطبيق. هذا يعني أنه يمكنك بسهولة تغيير التطبيقات التي يعتمد عليها كودك دون الحاجة لتعديل الشفرة المصدرية.
-
تجربة الوحدات: تجعل DI عمليات اختبار الوحدات (Unit Testing) أسهل. من خلال حقن الاعتماديات المزيفة (Mock Dependencies)، يمكنك اختبار كل وحدة منفصلة دون الحاجة لتوفير البيئة الخارجية.
-
إعادة استخدام الشفرة: يساعد استخدام DI في جعل الشفرة قابلة لإعادة الاستخدام بشكل أفضل. من خلال فصل الشفرة بين الاعتماديات والمنطق الأساسي، يمكنك استخدام الشفرة المكتوبة لأداء وظائف مختلفة بسهولة.
بناءً على الفوائد السابقة، يمكن أن نرى كيف يمكن أن يسهم استخدام Dependency Injection في تطوير تطبيقات قوية وقابلة للصيانة. ومع ذلك، فإن هذه الفوائد قد لا تكون ذات قيمة إذا لم يكن هناك حاجة لاستخدام الاختبارات المزيفة أو إذا كان المشروع صغير الحجم ولا يعاني من مشاكل الصيانة.
على الجانب الآخر، يمكن أن تعاني بعض المشاريع من بعض العيوب التي ذكرتها في المقال، مما يجعلها تفضل عدم استخدام DI. على سبيل المثال، إذا كانت الشفرة مشروعًا صغيرًا وليس هناك حاجة ماسة لاختبار الوحدات أو لتغيير الاعتماديات بانتظام، فقد يكون استخدام DI مبالغًا فيه.
بشكل عام، يجب أن تقوم بتقييم كل مشروع على حدة وفقًا لاحتياجاته الفريدة وحجمه ومتطلبات الصيانة والاختبارات. إذا كان استخدام DI يساعد في تحسين جودة الشفرة وتبسيط عملية التطوير، فقد يكون من المناسب استخدامه. ومع ذلك، إذا كان ذلك يضيف تعقيدًا غير ضروري ولا يوفر فوائد كافية، فقد تكون البدائل التقليدية مثل استخدام الـ static classes هي الخيار الأفضل.
