ما هي أفضل الممارسات لاستخدام أساليب الامتداد في .Net؟

Question

لقد رأيت هذه تُستخدم بكل الطرق، وتم اتهامي باستخدامها بطريقة خاطئة (على الرغم من أنني في هذه الحالة كنت أستخدمها بهذه الطريقة لإثبات وجودي). نقطة).

إذًا، ما رأيك في أفضل الممارسات لاستخدام أساليب الإرشاد؟

هل يجب على فرق التطوير إنشاء مكتبة لطرق الإرشاد ونشرها عبر مشاريع مختلفة؟

هل يجب أن تكون هناك مجموعة من طرق الإرشاد الشائعة في شكل مشروع مفتوح المصدر؟

تحديث:قررت إنشاء مكتبة أساليب الإرشاد على مستوى المؤسسة

Answer 1

الإصدار القادم من إرشادات تصميم الإطار، الإصدار الثاني سيحتوي على بعض الإرشادات لتنفيذ طرق الإرشاد، ولكن بشكل عام:

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

يجب عليك أيضًا تجنب توسيع System.Object حيث لن تتمكن جميع لغات .NET من استدعاء أسلوب الامتداد كملحق.(على سبيل المثال، سيحتاج VB.NET إلى الاتصال به كطريقة ثابتة عادية في فئة الامتداد الثابت.)

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

لا تحدد طريقة تمديد بنفس توقيع الطريقة "الحقيقية" حيث لن يتم استدعاؤها أبدًا.

Answer 2

قد ترغب في إلقاء نظرة على http://www.codeplex.com/nxl و http://www.codeplex.com/umbrella وكلاهما مكتبات طرق الامتداد.أنا شخصياً لم ألقي نظرة على الكود المصدري ولكنني متأكد من أن الأشخاص هناك سيكونون قادرين على إعطائك بعض المؤشرات الجيدة.

Answer 3

لقد قمت بتضمين طرق الامتداد الخاصة بي مع مكتباتي الأساسية في فئة Utils لأن الأشخاص الذين يعملون مع إطار العمل الخاص بي من المرجح أن يجدوا الطرق مفيدة، ولكن بالنسبة للنشر الشامل حيث قد يكون لدى المطور النهائي خيار مكتبات طرق الامتداد، أنصحك بوضع جميع امتداداتك في مساحة الاسم الخاصة بهم، حتى في ملف المشروع الخاص بهم، حتى يتمكن الأشخاص من اختيار إضافة مرجع أو عبارة استخدام أو ببساطة عند الاقتضاء، كما يلي:

Core.Extensions.Base64Encode(str);

إن فصل Utils الخاص بي هو أفضل صديق لي في العالم كله، وكان ذلك قبل ظهور طرق الإرشاد والتي ساعدت فقط في تعزيز علاقتنا.أكبر قاعدة سأتبعها هي منح الأشخاص خيار تحديد إطار الامتداد الذي يستخدمونه حيثما أمكن ذلك.

Answer 4

تحتوي لغة Objective-C على "فئات" منذ أوائل التسعينيات؛هذه هي في الأساس نفس طرق ملحق .NET.عند البحث عن أفضل الممارسات، قد ترغب في معرفة القواعد الأساسية التي توصل إليها مطورو Objective-C (Cocoa & NeXT) حولهم.

برنت سيمونز (مؤلف قارئ NetNewsWire RSS لنظامي التشغيل Mac OS X وiPhone) نشر اليوم للتو عنه قواعد النمط الجديد لاستخدام الفئات وكان هناك القليل من مناقشة في مجتمع الكاكاو حول هذا المنصب.

Answer 5

أعتقد أن ذلك يعتمد على الغرض الذي تخدمه طرق الامتداد.

• لا ينبغي تضمين أساليب الامتداد التي تتعلق باحتياجات عمل محددة للمشروع (سواء كانت مرتبطة بأنواع البيانات الأساسية أو الكائنات المخصصة) في مكتبة سيتم توزيعها عبر مشاريع متعددة.
• يمكن تجميع طرق الامتداد التي تتعلق بأنواع البيانات الأساسية (int، string، إلخ) أو الأدوية العامة التي لها تطبيق أوسع وتوزيعها عبر المشاريع.

احرص على عدم تضمين أساليب الامتداد التي ليس لها تطبيق يذكر على المستوى العالمي، لأنها تؤدي فقط إلى إعاقة التحسس الذكي ويمكن أن تؤدي إلى الارتباك و/أو سوء الاستخدام.

Answer 6

عندما اكتشفت الإضافات للمرة الأولى، أفرطت في استخدامها وأساءت استخدامها.

بالنسبة للجزء الأكبر، بدأت في الابتعاد عن استخدام أي طرق تمديد لعدد من الأسباب.

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

السبب الرئيسي وراء توقفي عن استخدام أساليب الامتداد هو أنه لا يمكنك معرفة بسرعة من خلال قراءة الكود مكان مصدر الطريقة ومن "يمتلكها".

عند قراءة الكود فقط، لا يمكنك معرفة ما إذا كانت الطريقة عبارة عن امتداد أم مجرد طريقة NET API قياسية من النوع.

يمكن لقائمة التحسس أن تصبح فوضوية بسرعة كبيرة.