إضافة دعم البرنامج المساعد: الواجهة أو الطبقة الأساسية للهث؟

Question

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

لماذا أختار واجهة بدلا من فئة البرنامج المساعد الأساسي للهث؟ هل يمكن أن تخبر أي تصميم يجب أن أختار ولماذا؟

Answer 1

يجب عليك التفكير في إلقاء نظرة على مساحة اسم System.Addin (MAF) أو إطار التسعة المدار (MEF). سيكون MEF الخيار المفضل على الرغم من أنه لا يزال قبل إصداره لأنه أبسط بكثير من MAF. إما واحدة من تلك الخيارات تبسط الكثير من أعمال السباكة التي ستحتاج إليها من أجل الحصول على الوظائف الإضافية المحملة والتفاعل معها.

بقدر ما يختار بين الواجهة وفئة مجردة، إذا ذهبت مع MAF أو MEF بعضها سيتم صنعها لك. معظم الاختلافات الأساسية في هذا السياق هي أنه من خلال توفير فئة قاعدة مجردة توفر نقطة ميراث للحصول على إضافات مخصصة (مكتوبة إما بواسطتك أو مطوري آخرين) وتأكد من أن طرق / خصائص معينة توفر السلوك الافتراضي وإجبار الفئات المشتقة على تنفيذ بعض الأساليب / الخصائص المطلوبة. العيب هو أنك تقتصر على فئة قاعدة واحدة.

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

Answer 2

استخدم واجهة لعقد البرنامج المساعد. إذا قام نوع معين من البرنامج المساعد بتشارك وظيفة معينة، فقم بإجراء فئة قاعدة مجردة تنفذ الواجهة. تأكد أيضا من أن عقودك موجودة في تجميع خارج تطبيقك الفعلي.

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

Answer 3

لماذا يجب أن تكون واحدة أو أخرى؟

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

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

public interface IPlugin
{
    void Initialize ();
    void Stuff ();
}

public class PluginBase : IPlugin
{
    protected abstract DoInitialize ();
    protected abstract DoStuff ();

    void IPlugin.Initialize { this.DoInitialize (); }
    void IPlugin.Stuff { this.DoStuff (); }
}

Answer 4

هناك وظيفة جيدة حول هذا الموضوع هنا:البرنامج المساعد API Design.

أنا شخصيا استخدام واجهة، واسمحوا الإضافات تنفذ كل التفاصيل.

Answer 5

أعتقد أن الشيء الواضح الذي يجب عليك فعله هو السماح للاتصال المساعد في تسجيل الاتصال (المندوبين) للأحداث الفردية التي تريد التعامل معها. هذه هي الطريقة التي تعمل بها معظم الأطر في .NET

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

كمثال، فإن أقسام "الأحداث" في أي عنصر تحكم ASP.NET معينة يفعل ذلك بهذه الطريقة: إلقاء نظرة على تحكم المستخدم

Answer 6

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

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

سيكون اقتراحي الشخصي هو الذهاب بنهج مثل واحد اقترحه سكواغنر وإنشاء كل من الفئة الأساسية وواجهة. وتشمل تحذيرا لمستخدمي الواجهة تفيد بأن الإصدارات المستقبلية قد تنكسر تنفيذها وأن استراتيجية الوراثة الأساسية الأساسية هي الوحدة الموصى بها لتجنب مشاكل التوافق في المستقبل.