فهم واجهات

Question

لدي طريقة فصلية تُرجع قائمة بالموظفين الذين يمكنني التكرار من خلالهم.ما هي أفضل طريقة لإرجاع القائمة؟عادةً ما أقوم بإرجاع ArrayList.ومع ذلك، كما أفهم، فإن الواجهات أكثر ملاءمة لهذا النوع من الإجراءات.ما هي أفضل واجهة للاستخدام؟أيضًا، لماذا من الأفضل إرجاع واجهة بدلاً من التنفيذ (على سبيل المثال كائن ArrayList)؟يبدو الأمر وكأنه الكثير من العمل بالنسبة لي.

Answer 1

أنا شخصياً سأستخدم أ قائمة<Employee> لإنشاء القائمة على الواجهة الخلفية، ثم استخدمها الأول قائمة عندما تعود.عند استخدام الواجهات، فإنها تمنحك المرونة لتغيير التنفيذ دون الحاجة إلى تغيير من يستخدم الكود الخاص بك.إذا كنت تريد الالتزام بقائمة ArrayList، فسيكون ذلك غير عام الأول قائمة.

Answer 2

@ جيسون

يمكنك أيضًا إرجاع IList<> لأن المصفوفة تنفذ هذه الواجهة بالفعل.

Answer 3

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

إن إرجاع قائمة بدلاً من ArrayList يعني أنه إذا قررت لاحقًا استخدام LinkedList، على سبيل المثال، فلن يتعين عليك تغيير أي من التعليمات البرمجية بخلاف المكان الذي أنشأت فيه الكائن للبدء به (أي استدعاء "جديد" قائمة المصفوفة ()).

Answer 4

إذا كان كل ما تفعله هو التكرار عبر القائمة، فيمكنك تحديد طريقة تُرجع القائمة كـ IEnumerable (لـ .NET).

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

Answer 5

هل هناك أي سبب لضرورة طلب المجموعة؟لماذا لا تقوم ببساطة بإرجاع ملف IEnumerable<Employee>؟وهذا يعطي الحد الأدنى المطلوب - إذا أردت لاحقًا شكلاً آخر من أشكال التخزين، مثل حقيبة أو مجموعة أو شجرة أو غير ذلك، فسيظل عقدك سليمًا.

Answer 6

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

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

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

أنا أقف متحدًا مع أولئك الذين ينصحونك بالابتعاد عن ArrayList.الأدوية العامة هي افضل بكثير.

Answer 7

الواجهة عبارة عن عقد بين التنفيذ ومستخدم التنفيذ.

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

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

Answer 8

أنت لا تقول ما هي اللغة التي تتحدث عنها، ولكن في شيء ما .NETish، فإن إرجاع IList ليس أكثر من مجرد قائمة أو حتى ArrayList، على الرغم من أن مجرد ذكر تلك الفئة القديمة يجعلني أعتقد أنك لا أتحدث عن .NET.

Answer 9

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

في الحالة التي تصفها، تمرير الواجهة لا يمنحك ميزة معينة، لو كنت أنا، لقمت بتمرير ArrayList بالنوع العام، أو تمرير المصفوفة نفسها:قائمة.toArray()

Answer 10

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

لديك السبب وراء ذلك في هذا المقال

Answer 11

يجب أن يكون نوع الإرجاع لطريقتك IList<Employee>.

وهذا يعني أن المتصل بالطريقة الخاصة بك يمكنه استخدام أي شيء IList العروض ولكن لا يمكن استخدام أشياء محددة لها ArrayList.ثم إذا شعرت في مرحلة ما بذلك LinkedList أو YourCustomSuperDuperList يقدم أداءً أفضل أو مزايا أخرى يمكنك استخدامه بأمان ضمن طريقتك وعدم إفساد المتصلين به.

هذا تقريبًا واجهات 101.؛-)