ضرورة الواجهات والحقن في مشروع فريد

Question

لماذا يجب أن أقوم بتنفيذ واجهات وحقن التبعية على الموقع دون أي فرصة تقريبًا لإعادة الاستخدام أو الترقية من قبل أي شخص آخر؟

Answer 1

عندما تعلمت كيفية برمجة جهاز كمبيوتر ، كنت تقوم بتطوير نوع من "ذاكرة العضلات" في حرفتك. على مر السنين ، تستمر في البرمجة في نفس العقلية. معظم الناس لا يتعلمون كل مبادئ OOP الأنيقة منذ البداية ، لذلك يبدو أنهم أكثر جهدًا من الطريقة التي تعلموها.

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

Answer 2

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

Answer 3

لماذا الواقع؟

لا أعتقد أن الواجهات والحقن تتعلق فقط بإعادة الاستخدام أو الترقية.

أنا شخصياً أستخدم الواجهات و DI لجميع المشاريع. لا يكفي النفقات العامة لجعل تجنبهم فائدة.

Answer 4

لأن الافتراض الذي تقوم به هو نفس الافتراض الذي أدى إلى Y2K.

Answer 5

أجد أنه يجعل من الأسهل بكثير إعادة استخدام الكود بطرق لم أفكر فيها بعد. كما أنه يسهل تغيير كيفية عمل الرمز دون تغيير رمز المصدر.

انا استخدم Spring.net لحقن التبعية.

دعنا نقول أن لديك فئة آلة لها وظيفة Dowork (). ثم تقوم بإنشاء واجهة iworkalgorithm ، مع تطبيقات خوارزمية محددة لكل جهاز.

يحتوي كل مثيل من الجهاز على iWorkalgorithm تم حقنه فيه ، و Machine.Dowork () يستدعي التنفيذ المحقن.

الآن لديك المزايا التالية:

1. يمكنك التبديل في تطبيقات جديدة فقط عن طريق تحرير ملف XML.
2. يمكنك تغيير خصائص كل تطبيق (مهلة ، حدود ، إلخ) عن طريق تحرير ملف XML.
3. يمكنك إعادة استخدام تطبيقاتك خارج فئة الماكينة.

Answer 6

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

لا تنسى أن "المطور الآخر" على برنامجك يمكن أن يكون أنت. يمكنك اختراق مجموعة من التعليمات البرمجية المقترنة للغاية والمعتمد على العمل ، وحتى فهمها أثناء العمل عليها ، ولكن في اللحظة التي تبتعد فيها عن المشروع ، حتى لبضعة أيام ، ستبدأ لنسيان كل الأشياء الصغيرة التي منعت كرة الغزل من الانهيار.

عندما تعود إليها (ولا يزال يتعين عليّ رؤية جزء من البرامج التي لم تتطلب بعض التغييرات على الطريق) ، ستتمنى أن تكون قد اتبعت أفضل الممارسات.