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

Question

لا بد لي من تنفيذ Java.Polynomial كمهمة مدرسية.جزء من الأساليب هي إضافة (متعددة الحدود), ضرب (متعدد الحدود) إلخ.

في حالة شيء مثل

p.add(q); // computes p + q

هل من الأفضل إرجاع الفراغ والاحتفاظ بمجموع كثيرات الحدود في p؟أم أنه من الأفضل إرجاع كثير الحدود والحفاظ على القيمة السابقة لـ p سليمة؟

غريزتي تقول لي أن علي أن أفعل ما يلي

• قم بتنفيذ p.add(q) كطريقة "مدمرة"...يضيف q إلى قيمة p ويخزن المبلغ في p
• قم أيضًا بتنفيذ طريقة ثابتة Polynomial.add(p,q) والتي تُرجع مجموع كثيرات الحدود.

ماذا تعتقد؟

Answer 1

أنا شخصياً أحب الأنواع غير القابلة للتغيير.أود أن أكتب p.plus(q) بدلاً من p.add(q) وجعلها ترجع كثيرة الحدود جديدة.إن الثبات له تأثير كبير، ليس فقط فيما يتعلق بسلامة سلسلة الرسائل (والتي يبدو أنها لن تكون مشكلة في هذه الحالة) ولكن أيضًا من حيث التفكير في التعليمات البرمجية الخاصة بك.من الأسهل كثيرًا التنبؤ بما سيحدث إذا كنت تعلم أنه لا يوجد شيء يمكنه تغيير محتويات كائن ما تحت قدميك بمجرد قيامك بإخفاء إشارة إليه.

Answer 2

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

الفئة غير القابلة للتغيير الأكثر شهرة هي String.

Answer 3

"من الأفضل إرجاع كثيرة الحدود والحفاظ على القيمة السابقة لـ p سليمة"

الحياة أفضل إذا جعلت أنواعك الرقمية تتصرف مثل الأرقام الأخرى.

تعتبر العمليات "المدمرة" شرًا لا بد منه عندما يتعين عليك تحسين الأداء عن طريق تقليل تخصيصات الذاكرة.

وتتمثل المقايضة في أن المعالجة الخاصة بك تصبح معتمة بسبب تغيرات الحالة الأكثر تعقيدًا في المتغيرات.أنت لا تريد تغيير الحالة المخفية؛تريد أن تكون تخصيصاتك للقيم للمتغيرات أمرًا كبيرًا وواضحًا من الدرجة الأولى، مع نوع من الأشياء.

Answer 4

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

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

Answer 5

حتى لو استخدمت الطريقة "المدمرة"، فسوف ترغب في إرجاع القيمة الجديدة على أي حال للسماح بتسلسل الوظائف.وعلى الرغم من ذلك، عندما واجهت نفس المشكلة بالنسبة لـ BigInteger وBigDecimal، قررت Sun أن تصبح غير مدمرة.

Answer 6

اجعلها غير قابلة للتغيير، واجعل الواجهة مماثلة لواجهة BigInteger (بقدر الإمكان).

Answer 7

هل من الأفضل إرجاع الفراغ والاحتفاظ بمجموع كثيرات الحدود في p؟

ليس سيئًا، وليس بالضرورة أفضل أيضًا.

أم أنه من الأفضل إرجاع كثير الحدود والحفاظ على القيمة السابقة لـ p سليمة؟

إنه أفضل وأقل مفاجآت وأسهل في الفهم والصيانة.(على الرغم من أنه سيتعين عليك إنشاء المزيد من المتغيرات)

Answer 8

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