هناك العديد من المشاريع من نوع Simple Injector للغات البرمجة المختلفة التي تسمح ، باسم فئة أو واجهة أو مساحة اسم ، وأحيانًا مجلد ، بتسجيل فصل دراسي أو مجموعة كاملة من الفئات التي توحدها هذه الميزة في بعض الحالات. يتم ذلك لغرض إنشاء مثيل لكائن تلقائيًا دون تحديد تبعياته بشكل صريح. هذا التسجيل لمجموعة من الكائنات بواسطة ميزة مشتركة في السجل لغرض مزيد من إنشاء مثيل ، أسمي التسجيل التلقائي للتبعيات.
إذا قمت بإنشاء مثيل لفئة ما بشكل صريح عند تسجيلها في سجل التبعية ، فهذا ليس موضوع هذه المقالة.
وما الخطأ في ذلك؟
في هذا المنشور ، سأتحدث عن إحباطاتي من المشاريع التي تستخدم تسجيل التبعية التلقائي. دعنا نذهب بالترتيب.
وقت التشغيل مقابل وقت التجميع
باستخدام أداة تسجيل التبعية التلقائية ، نقوم بنقل التحقق من اكتمال التبعيات المسجلة إلى وقت التشغيل. أي ، إذا لم يكن لدينا في وقت بدء تشغيل البرنامج تنفيذ الواجهة اللازمة لتنفيذ الكود ، فسوف نتعرف عليها في أفضل الأحوال في بداية التطبيق ، وفي أسوأ الأحوال - بالفعل أثناء تشغيل النظام ومن المستخدمين.
هنا مثال. إذا حدث تسجيل بعض الفصول في المشروع ، على سبيل المثال ، من خلال مساحة الاسم الخاصة بهم ، وقمت في وقت ما بنقل الفصل منه ، فستتعرف على المشكلة في وقت التشغيل. سيحدث نفس الشيء مع التسجيل التلقائي عبر الواجهة ، مع الاختلاف الوحيد وهو أن النقل لن يكون مشكلة ، ولكن إزالة الواجهة ستؤدي إلى مشكلة ستتعرف عليها بعد بدء التطبيق.
إعادة الهيكلة أكثر تعقيدًا
ليس فقط إعادة الهيكلة ، ولكن أيضًا تعلم الكود يصبح صعبًا للغاية هذا لأنه عند استخدام التسجيل التلقائي للتبعيات ، يتم فقد الوصول إلى الإمكانات الحديثة لبيئات التطوير ، مما يسمح لنا بمعرفة من يستخدم هذه الفئة بنقرة واحدة (ابحث عن المرجع) والإجابة على الأسئلة التالية:
- هل يمكنني إزالة هذا الفصل؟
- هل يمكنني نقل هذه الفئة إلى مساحة / مجلد آخر؟
إلخ
بالإضافة إلى حقيقة أننا محرومون من فرصة التحقق من اكتمال التبعيات المطلوبة أثناء التجميع ، فإن أي إعادة بناء هو الأمل في أن يكون لدينا آلية وقت تشغيل في شكل اختبارات ، والتحقق من أشجار التبعية ، وما شابه. والأمل أن يعمل. وتجدر الإشارة إلى أن هذه الآليات لا تضمن فقط 100٪ أن تكوين الكود صحيح ، ولكن أيضًا أبطأ بكثير من التجميع.
إخفاء التعقيد الحقيقي للنظام
عند إنشاء مثيل للفئات يدويًا وجميع تبعياتها ، قد تخاف من فظاعة الملف الذي سيحدث فيه كل هذا الإجراء. بالنظر إلى آلاف الأسطر من التعليمات البرمجية لإنشاء مثيل للفئات ومقارنتها بالعشرات عند استخدام تسجيل التبعية التلقائي ، أريد حقًا الاستسلام للإغراء والذهاب إلى "الجانب المظلم".
ولكن ما هي آلاف الأسطر من التعليمات البرمجية التي تخبرنا عن إنشاء مثيل لها؟ حقيقة أن هذه الوحدة معقدة وكبيرة ، ويجب أن نفكر إما في هيكلتها من خلال تخصيص الوحدات الفرعية (التي تُنشئ نفسها صراحةً تبعياتها) ، أو تقسيم هذه الوحدة إلى عدة.
قد يبدو الأمر مجرّدًا ، لكن إزالة اللحظات المحرجة مثل إنشاء مئات العناصر من أعيننا يؤدي إلى حقيقة أن حجم المشروع ينمو بشكل لا يمكن السيطرة عليه ، ونتيجة لذلك ، نفوت اللحظة التي يجب تقسيمها إلى عدة مشاريع.
التبعيات الإضافية
من خلال تسجيل التبعيات وعدم التحكم في استخدامها ، نصل عاجلاً أم آجلاً إلى موقف يتم فيه تسجيل فئات أكثر بكثير مما هو مطلوب بالفعل في بداية التطبيق. يمكن أن يؤدي مجرد الإضافة إلى مجلد أو تنفيذ واجهة إلى تسجيل هذه الفئة في الحالة العامة.
ملخص
هل يمكن العيش مع كل هذه العيوب وعدم ملاحظتها؟ أكيد! لكنني أعتقد أنه يطور عادات التنمية الخاطئة. النقطة المهمة هي أن تجميع الكود وكتابته هما أدوات للتحقق من صحة النظام. برفضهم ، توصلنا إلى حقيقة أن النظام أصبح هشًا ، لذلك يخشى المطورون تغيير أي شيء فيه. ويؤدي خوف المطورين من تغيير الكود بالفعل إلى حقيقة أن جودة قاعدة الكود تتدهور ، وبعد ذلك يصبح إجراء تغييرات على هذا الرمز عملية مكلفة.
ما الجيد في التسجيل التلقائي للتبعية؟
وحقاً ، ما هو الجيد؟ أقترح أن أناقش في التعليقات سبب اكتساب هذه الطريقة شعبية. بالتأكيد لديه معجبين بين قرائه.