متى ترغب في عدم تطبيق Tostring () في Java؟

Question

لقد اتخذ مطورا رئيسيا في مشروعي للإشارة إلى تطبيقات Tostring () المشروع ك "Cruft نقية" ويتطلع إلى إزالتها من قاعدة التعليمات البرمجية.

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

الآن على وجه التحديد، فإن الكائنات الموجودة في هذا النظام هي عناصر جرافيك مثل المستطيلات والدوائر وما إلى ذلك والتمثيل الحالي هو عرض X و Y و Scale أو Bounds، إلخ ...

إذن، أين يكذب الحشد؟

متى يجب عليك ومتى يجب ألا تنفذ Tostring؟

Answer 1

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

شخصيا، سأخطئ دائما على جانب وجود طريقة Tostring () القابلة للتطبيق. القليل من العمل للكتابة.

Answer 2

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

أنا حقا لا أستطيع التفكير في سبب وجيه للالتفاف من هذه.

Answer 3

لقد تأكدت دائما من أن فصالتي تنفذ Tostring.

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

Answer 4

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

Answer 5

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

Answer 6

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

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

ToStringBuilder.reflectionToString(myObject);

أو يجب أن تتصل رمز العميل فقط بيوتات الخصائص القياسية وسجل الطريقة التي يعجبهم ...

Answer 7

بشكل عام، toString() هي الأشياء الجيدة. على وجه الخصوص، هو مفيدة جدا لتصحيح الأخطاء.

تنفيذ toString() ليس بدون التكاليف و المخاطر. وبعد مثل كل الكود، toString() يجب الحفاظ على التطبيقات مع بقية الكود. هذا يعني الحفاظ على toString() في المزامنة مع الحقول الفئة. على سبيل المثال، عند إضافة حقل أو إزالته، toString() يجب أن يتم تحديثها بشكل مناسب (يجب أن تفعل هذا بالفعل لطرق مثل hashCode() و equals()).

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

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

Answer 8

انا دائما توليد السيارات طرق Tostring () لجميع بلدي POJOس، DTOS و / أو أي كائن يحمل بيانات مستمرة. بالنسبة للخصائص الداخلية الخاصة ممارسة تسجيل جيدة يجب أن تفعل الخدعة.

تذكر دائما استبدال كلمات مرور أساليب Tostring وغيرها من المعلومات الصالحة [Omitted] (أو شيء مماثل من أعلى الطبيعة Secrete)

Answer 9

حسنا، يفعل شيء سترام.

لا أستطيع أن أقول Tostring () مفيد للغاية. لعرض تقديمي سوف تحتاج إلى أدوات أخرى.

لكن ToString () مفيد للغاية لتصحيح الأخطاء، لأنك تستطيع أن ترى محتويات المجموعات.

أنا لا أفهم لماذا أخرجه إذا كان مكتوب بالفعل

Answer 10

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

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

Answer 11

+1 مايك ج

انتهت وفوق فائدتها لتصحيح الأخطاء، The Tostring () أداة لا تقدر بثمن لفهم منظور مؤلف الفصل للمثيل.

FWIW، إذا اختلاف إخراج Tostring عن ما تتوقع رؤيته (مستندات المواصفات المجاملة)، فسوف تعرف شيئا ما حدث خطأ بجدية.

Answer 12

شخصيا، أقوم بتنفيذها عندما أستخدم الكائنات في قائمة jtable أو JTable أو هيكل آخر يستخدم ToString () أو عندما أخيص تصحيح (نعم، Eclipse يحتوي على تصحيح تصحيح الأخطاء ولكن ToString () أسهل).

ربما يمكنك إطلاق النار على أن العديد من فئات JDK لديها Tostring (). يجب إزالتها كذلك؟ ؛)

Answer 13

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

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

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

وأنا أتفق مع jisight أنه إذا كانت مكتوبة بالفعل، والكتابة لائق، فاتركها على الأقل حتى يحصلوا على الطريق (مثل إضافة حقل فعلا إلى فئة).

Answer 14

لأغراض تصحيح الأخطاء، لا يمكن لأحد التغلب عليها toString. وبعد من العملي في مصحح الأخطاء، وفي طباعة تصحيحات بسيطة. تأكد من عرض جميع الحقول التي equals و hashCode تستند الأساليب، إذا تجاوزت تلك أيضا!

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

Answer 15

من المعلن أن يكون لديك دائما مشاكل في توسيلات تظهر القليل جدا أو الكثير من المعلومات.

قد يكون من المنطقي أن تستخدم فريقك لاستخدام Tostringbuilder في Jakarta Commons Lang بدلا من ذلك:

System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));

مما يدل على الكائن، وطبع الحقول العامة.

http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/builder/tostringbuilder.html.

Answer 16

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

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

Answer 17

أن نكون منصفين، وقال المطور هنا، ولكن لا يؤدي المطور بأي حال من الأحوال.

القضية الأصلية ليست بالضرورة حول toString ()، ولكن حول الطريقة الثانية من الأسلوب الثاني

يرى http://code.google.com/p/piccolo2d/issues/detail؟id=99.

Answer 18

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

Answer 19

إذا كانت هناك مشكلة مع القائمة toString() التطبيقات، يجب على المطور إصلاح المشكلة. قول التنفيذات الحالية كلها "Cruft نقية" وإزالتها تؤذي بنشاط، ما لم تكن موجودة toString() الأساليب غير مألوف كتب بشكل سيئ.

أود بقوة تثبيط المطور من إزالة أي عمل toString() طريقة.

Answer 20

تنفيذ دائما :) كما هو مذكور أعلاه، فإنه لا يقدر بثمن لتصحيح الأخطاء.

Answer 21

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

لذلك فيما يتعلق

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

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

Answer 22

برغم من toString() الأساليب مفيدة للغاية بالنسبة لفئات قيمة التصحيح، ويمكن القول أنها ليست مفيدة لفئات الكيان.

Answer 23

اعتقدت أنني كنت أزن مع منظور أكثر حداثة بالنظر إلى أن هذا السؤال هو الآن ما يقرب من 10 سنوات.

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

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

إذن ما الذي يمكننا فعله لمعالجة هذه المشاكل دون إزالة الطريقة تماما؟ الجواب هو توليدها تلقائيا. مشروع لومبوك @ToString حاشية. ملاحظة يمكن أن تولد تلقائيا toString الطريقة بالنسبة لك في وقت الترجمة التي تتضمن أي مجموعة من الحقول التي تختارها.

استخدام العينة الأساسية:

@ToString
public class Foo {
    private int i = 0;
}

والتي ستصبح مكافئ لما يلي في تجميع الوقت:

public class Foo {
    private int i = 0;

    public String toString() {
        return "Foo(i=" + this.i + ")";
    }
}

Answer 24

نحصل على concurrentmodificationsexception من إحدى طرق Tostring () لدينا، لذلك هناك عيب عرضي. بالطبع إنه خطأك لعدم مزامنة.