الزائفة متعددة الميراث مع طرق التمديد على واجهات في C #؟

Question

سؤال مماثل ولكن ليس نفس الشيء

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

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

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

Answer 1

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

قل لدي طريقة تأخذ كائن من نوع ibar. إذا قمت بتطبيق واجهة IBAR على فئة FOO عبر طرق الإرشاد، فلن تستمد FOO FOO من IBAR ولا يمكن استخدامها بالتبادل معها (مبدأ استبدال Liskov). بالتأكيد، أحصل على السلوك الذي أريد إضافته إلى فو، لكنني أخسر الجانب الأكثر أهمية في إنشاء واجهات في المقام الأول - القدرة على تحديد عقد مجردة يمكن تنفيذها بعدة طرق من خلال فئات مختلفة بحيث يجب ألا تعرف الفصول المعالين عن تطبيقات الخرسانة.

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

Answer 2

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

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

نظرا لأن هذه هي الفائدة الرئيسية للواجهات، فإن تنفيذها بالكامل كما يبدو أن طرق الإرشاد تهزم هدفها. حتى في IEnumerable<T> لديه طريقة مثيل.

يحرر: أيضا، تهدف الكائنات إلى التصرف على البيانات التي تحتوي عليها. يمكن أن ترى طرق الإرشاد فقط API للكائن العام (لأنها مجرد طرق ثابتة)؛ عليك أن تعرض كل دولة كائن لجعلها تعمل (لا-لا).