هل يحتوي على الكل () ويحتفظ بالكل () في أصل عنوان واجهة المجموعة؟

Question

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

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

على سبيل المثال، تنص Bag in apache-collections صراحةً على أنها تحترم العلاقة الأساسية، وتدعي أنها تنتهك عقد الإصدار من Collection (على الرغم من أنها لا تفعل ذلك حقًا).

إذًا، ما هي دلالات هذه العمليات في المجموعة وليس في المجموعة المجردة؟

يحرر:أولئك الذين يتساءلون عن سبب اهتمامي، لأنه كجزء من رسالة الدكتوراه.لقد أوضحت في العمل أن المطورين لا يتوقعون انتهاك التوافق في Apache، لكنني أحاول أن أفهم سبب ترك واجهة المجموعة غامضة للغاية.

Answer 1

يقول javadocs لـ يحتوي على الكل (في المجموعة):

عائدات:صحيح إذا كانت هذه المجموعة تحتوي على جميع العناصر في المجموعة المحددة

وللاحتفاظ بالكل (في المجموعة):

يحتفظ فقط بالعناصر في هذه المجموعة الواردة في المجموعة المحددة (التشغيل الاختياري).بمعنى آخر ، يزيل من هذه المجموعة جميع عناصرها غير الواردة في المجموعة المحددة.

قرأت عقد يحتوي على كل ما يعني أن استدعاء a.containsAll(b) سيعود صحيحًا، إذا وفقط إذا كان استدعاء a.contains(bElem) لكل عنصر bElem في b سيعود صحيحًا.وأود أيضًا أن أعتبر ذلك يعني ضمناً أن a.containsAll(someEmptyCollection) سيعود أيضًا صحيحًا.كما ذكرت javadocs لـ AbstractCollection بشكل أكثر وضوحًا:

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

أوافق على أن تكون جهة الاتصال الخاصة بالتجميع لـ يحتوي على الكل أكثر وضوحًا لتجنب أي احتمال للارتباك.(وأن قراءة javadocs لـ AbstractCollection لا ينبغي أن تكون ضرورية لتأكيد فهم المجموعة)

لم أكن لأفترض فيما يتعلق بعدد العناصر المكررة بعد استدعاء الاحتفاظ بالكل.لا يشير العقد المذكور في المجموعة (من خلال قراءتي) في كلتا الحالتين إلى كيفية التعامل مع التكرارات في أي من المجموعتين.بناءً على قراءتي لـretainAll في المجموعة، فإن النتائج المحتملة المتعددة لـ a.retainAll(b) كلها معقولة:

1. تحتوي النتيجة على 1 من كل عنصر يحتوي على نسخة واحدة على الأقل في كل من a وb
2. تحتوي النتيجة على كل عنصر (بما في ذلك التكرارات) كان موجودًا في a، باستثناء العناصر غير الموجودة في b
3. أو حتى، تحتوي النتيجة في مكان ما بين 1 وعدد النسخ الموجودة في كل عنصر في أ، باستثناء تلك غير الموجودة في ب.كنت أتوقع رقم 1 أو رقم 2، لكنني سأفترض أن أيًا من الثلاثة قانوني بناءً على العقد.

تؤكد javadocs لـ AbstractCollection أنها تستخدم رقم 2:

يتكرر هذا التنفيذ حول هذه المجموعة ، والتحقق من كل عنصر يتم إرجاعه بواسطة Iterator بدوره لمعرفة ما إذا كان موجودًا في المجموعة المحددة.إذا لم تكن موجودة ، فسيتم إزالتها من هذه المجموعة باستخدام طريقة إزالة التكرار

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

ربما ينبغي عليك التفكير في إرسال التحديثات المقترحة إلى JavaDoc بمجرد الانتهاء من ذلك.

فيما يتعلق بـ "سبب ترك واجهة المجموعة غامضة للغاية" - فأنا أشك بشدة في أنه تم ذلك عن عمد - ربما كان مجرد شيء لم يُمنح الأولوية الواجبة عند كتابة هذا الجزء من واجهات برمجة التطبيقات.

Answer 2

وأنا لا أعتقد أن مجموعة تعرف أنه بهذه الطريقة أو تلك، ولكنه ببساطة أصبح نوعا من اتفاقية لمتابعة سلوك AbstractCollection، على سبيل المثال <لأ href = "http://google-collections.googlecode.com" يختلط = "نوفولو noreferrer"> جوجل-مجموعات لا: انظر <لأ href = "http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Multiset.html #containsAll (java.util.Collection) "يختلط =" نوفولو noreferrer "> على مولتيست الوثائق (ومولتيست هو ما يسمونه كيس)