override شدن متدهای toString و equals ؟

[kiani2012]

سلام
جایی مطالعه کردم که کلاس Object پدر تمامی کلاسهای جاواست و این دو متد از متدهای کلاس Object هستند (البته متدهای دیگر هم هستن) و برای استفاده از این دو متد باید آنها را Override کنیم
چندتا سوال برام بوجود اومده :
1-اگر این دو متد را override نکنیم استفاده از اونها برای شیء هامون چه خروجی خواهد داشت ؟
2-فرض بر اینکه این دومتد متدهای کلاس آبجکت نبودند، ما باز هم میتونستیم همون تعریفی که در ذهنمون هست برای این دو تابع در کلاس مورد نظرمون انجام بدیم و همون نتیجه رو بگیریم حالا فلسفه اینکه این متدها به ارث برده بشن و بعد Override بشن چیه؟ چه سودی دار؟

البته برای متد toString() میشه گفت برای اینکه این متد از کلاس object هست و جاوا هم اونو میشناسه و توسط برنامه نویس Override میشه به جای اینکه برای چاپ شیء از دستور

Sysytem.out.println(obj.toString ());

استفاده کنیم دستور زیر را استفاده خواهیم کرد:

System.out.println( obj);

[vahid-p]

با سلام. بایدی در کار نیست.
1- در این صورت equals در صورتی true خواهد بود که هر دو آبجکت دقیقا یک آبجکت باشند. اما در صورتی که override کنید میتونید برابری رو هر جور که میخواید تعریف کنید. برای toString هم اسم کلاس @ و یه شماره هست که فکر میکنم آی دی اون آبجکت باشه.
2- باید بدونید فواید override چی هست در کل. مثلا اگر متد toString در Object وجود نداشت، هر کلاسی ممکنه این متد رو پیاده سازی نکنه و در این صورت System.out.println(obj) خطا خواهد داد. اما وقتی یک کلاسی از یک پرنت ارث میبره آبجکت اون کلاس همه جا میتونه جای اون پرنت بشینه و نگرانی بابت این موضوع نداریم. این کار حتی باعث میشه برنامه هامون خیلی جمع و جورتر بشن و لازم نباشه برای انواع کلاس ها مثلا System.out.println جداگانه تعریف کنیم.

[kiani2012]

سلام ممنون از پاسخت این قسمتو درست متوجه نشدم
میشه بیشتر توضیح بدید؟

اما وقتی یک کلاسی از یک پرنت ارث میبره آبجکت اون کلاس همه جا میتونه جای اون پرنت بشینه و نگرانی بابت این موضوع نداریم. این کار حتی باعث میشه برنامه هامون خیلی جمع و جورتر بشن و لازم نباشه برای انواع کلاس ها مثلا System.out.println جداگانه تعریف کنیم.

[vahid-p]

سلام ممنون از پاسخت این قسمتو درست متوجه نشدم
میشه بیشتر توضیح بدید؟

میخوام بگم در کد نویسی به شدت صرفه جویی میشه. در خیلی از متدها (توابع) شما لازم نیست برای انواع کلاس های شبیه به هم (یعنی دارای یک والد parent) چندین متد بنویسید. کافیه یکی برای اون والد بنویسید و بقیه فرزند ها میتونن به جای اون والد در اون متد قرار بگیرن.
از همون مثالهایی که در شی گرایی زیاد میزنن، بگم شاید بهتر باشه: فرض کنید ما یک تابع داریم که یک خودرو رو به عنوان ورودی میگیره و تعداد چرخ هاش رو مشخص میکنه.
خب حالا اگر رابطه والد/فرزندی در شی گرایی استفاده نکنیم، ما باید یک تابع برای پراید بنویسیم، یک تابع برای پژو یک تابع برای X.
برای همین ما میاییم یک سری خصیصه های مشترک رو به عنوان کلاس خودرو تعریف میکنیم. حالا فرزندهای این کلاس میتونن خصیصه های بیشتری رو داشته باشند یا خصیصه های والد رو تغییر بدن. اما در هر حال اگر خصیصه تعداد چرخ در والد وجود داشته باشه، پس تمام فرزندهاش هم این خصیصه رو دارن.
پس اگر تابعمون بگیم مقدار خصیصه تعداد چرخ رو چاپ کن، الان هر آبجکتی از پژو یا پراید میتونه اینجا قرار بگیره در صورتی که ما خودرو رو به عنوان ورودی تابع تعریف کردیم ولی چون پژو و پراید فرزند کلاس خودرو هستند، خصیصه های اون رو به ارث بردن و در نتیجه حتما این خصیصه رو دارن پس مشکلی پیش نمیاد. در غیر این صورت تضمینی در داشتن اون خصیصه ها نیست.

[kiani2012]

میخوام بگم در کد نویسی به شدت صرفه جویی میشه. در خیلی از متدها (توابع) شما لازم نیست برای انواع کلاس های شبیه به هم (یعنی دارای یک والد parent) چندین متد بنویسید. کافیه یکی برای اون والد بنویسید و بقیه فرزند ها میتونن به جای اون والد در اون متد قرار بگیرن.
از همون مثالهایی که در شی گرایی زیاد میزنن، بگم شاید بهتر باشه: فرض کنید ما یک تابع داریم که یک خودرو رو به عنوان ورودی میگیره و تعداد چرخ هاش رو مشخص میکنه.
خب حالا اگر رابطه والد/فرزندی در شی گرایی استفاده نکنیم، ما باید یک تابع برای پراید بنویسیم، یک تابع برای پژو یک تابع برای X.
برای همین ما میاییم یک سری خصیصه های مشترک رو به عنوان کلاس خودرو تعریف میکنیم. حالا فرزندهای این کلاس میتونن خصیصه های بیشتری رو داشته باشند یا خصیصه های والد رو تغییر بدن. اما در هر حال اگر خصیصه تعداد چرخ در والد وجود داشته باشه، پس تمام فرزندهاش هم این خصیصه رو دارن.
پس اگر تابعمون بگیم مقدار خصیصه تعداد چرخ رو چاپ کن، الان هر آبجکتی از پژو یا پراید میتونه اینجا قرار بگیره در صورتی که ما خودرو رو به عنوان ورودی تابع تعریف کردیم ولی چون پژو و پراید فرزند کلاس خودرو هستند، خصیصه های اون رو به ارث بردن و در نتیجه حتما این خصیصه رو دارن پس مشکلی پیش نمیاد. در غیر این صورت تضمینی در داشتن اون خصیصه ها نیست.

بله درسته ممنون