שאלה על תכונות עצמים

[davidcohen]

אוקיי תיקנתי.

אבל יש לי בעיה בשיטה הבאה:

public String toString(){
		for (int i=0; i<phoneBook.length; i++){
			return phoneBook[i].toString();
		}
	}

הוא רושם לי שהשיטה חייבת להחזיר string ואני לא מבין מה הבעיה.

ד"א זו השיטה toString מהמחלקה Entry :

public String toString(){
		return ("First name:"+this.firstName +"\n"+ "Last name:"+this.lastName +"\n"+ "Telephone number:" + this.phoneNumber);
	} 

[שניצל]

קודם כל, כשאתה עושה return אז הפונקציה מיד יוצאת. במקרה שלך, הפונקציה תצא באיטרציה הראשונה של הלולאה, ככה שרק הרשומה הראשונה תוחזר.

חוץ מזה, הוא צועק כי יש מקרים שבהם הפונקציה לא תגיע ל-return (תחשוב מה קורה אם ה-phoneBook ריק).

[davidcohen]

אז איך אני מונע את היציאה ?

רקורסיה?! אני פשוט לא כל כך זוכר רקורסיה...

[שניצל]

אלוהים אדירים, למה רקורסיה?

איך אתה מונע את היציאה? אתה לא עושה return בכל איטרציה, אלא רק return אחד.

קודם כל, תחשוב מה אתה רוצה בכלל שהפונקציה תעשה.

[sharonbn]

davidcohen

אני לא רוצה לבלבל אולם אם אתה רוצה ללמוד ג'אווה חשוב שתדע - השיטה equals כפי שכתבת במחלקה Entry אינה כתובה נכון.

ז"א היא תעבוד אולם היא לא דורכת (override) על השיטה בעלת השם הזה במחלקה Object (וזו הכוונה של מי שכותב שיטה equals).

זה קשור למושג ירושה ואיך הוא ממומש בג'אווה. השיטה שלך תיקרא רק אם אתה משווה עצמים מטיפוס Entry אני מנחש שבקוד שלך לא יהיה מצב אחר (כלומר השוואה של עצמים מטיפוסים שונים) אולם למען התכנות הנכון אתה צריך לשנות את החתימה של השיטה.

אם זה לא ברור אשמח לפרט.

עריכה:

בנוסף לאמור למעלה לא ברור לי למה השיטה בודקת שוויון של שם פרטי ומשפחה אבל לא של מספר טלפון וההשוואה של מספר טלפון נעשית במחלקה PhoneBook

הרי ההגדרה של שויון בין עצמים מטיפוס Entry היא שכל שלושת משתני המחלקה שווים. ההגדרה הזו (בשלמותה) צריכה להיות מקודדת בשיטה equals וככה תוכל להוציאה מ addEntry

[davidcohen]

davidcohen

אני לא רוצה לבלבל אולם אם אתה רוצה ללמוד ג'אווה חשוב שתדע - השיטה equals כפי שכתבת במחלקה Entry אינה כתובה נכון.

ז"א היא תעבוד אולם היא לא דורכת (override) על השיטה בעלת השם הזה במחלקה Object (וזו הכוונה של מי שכותב שיטה equals).

זה קשור למושג ירושה ואיך הוא ממומש בג'אווה. השיטה שלך תיקרא רק אם אתה משווה עצמים מטיפוס Entry אני מנחש שבקוד שלך לא יהיה מצב אחר (כלומר השוואה של עצמים מטיפוסים שונים) אולם למען התכנות הנכון אתה צריך לשנות את החתימה של השיטה.

אם זה לא ברור אשמח לפרט.

עריכה:

בנוסף לאמור למעלה לא ברור לי למה השיטה בודקת שוויון של שם פרטי ומשפחה אבל לא של מספר טלפון וההשוואה של מספר טלפון נעשית במחלקה PhoneBook

הרי ההגדרה של שויון בין עצמים מטיפוס Entry היא שכל שלושת משתני המחלקה שווים. ההגדרה הזו (בשלמותה) צריכה להיות מקודדת בשיטה equals וככה תוכל להוציאה מ addEntry

אלו ההוראות מהספר, גם חטימת השיטה וגם ההשוואות...

וזה מה שעשיתי בסוף, זה טוב ?

public String toString(){
		String s = " ";
		for (int i=0; i<phoneBook.length; i++){
			if (phoneBook[i]!=null){
				s = s +"\n" + phoneBook[i].toString();
			}
		}
		return s;			
	}

[שניצל]

מעולה.

אגב, יש אנשים שימליצו לך להשתמש ב-StringBuilder, שהוא קלאס שמיועד לבניית מחרוזות.

[sharonbn]

אלו ההוראות מהספר, גם חטימת השיטה וגם ההשוואות...

אין לי ענין להתווכח איתך. מצידי אתה יכול להתעלם.

אולם תדע שאם למשל תרצה למיין את האיברים של המערך phoneBook באמצעות המחלקה Arrays (המחלקה נותנת הרבה שירותים למערכים, כמו מיון חיפוש בינארי ועוד. כדאי להכיר אותה) אזי המיון יכול להכשל עם השיטה כפי שהיא כתובה כעת (למשל אם ישנן כניסות עם אותו שם פרטי ומשפחה אבל עם טלפונים שונים)

[br]פורסם בתאריך: 25.01.2010 בשעה 11:48:42

---

מעולה.

אגב, יש אנשים שימליצו לך להשתמש ב-StringBuilder, שהוא קלאס שמיועד לבניית מחרוזות.

לפי דעתי אין צורך. בין כה הקומפיילר מחליף חיבור של מחרוזות בקריאה ל StringBuffer (וכל ההבדל בין StringBuffer ו StringBuilder הוא סינכרוניזציה)

הרווח בביצועים הוא מזערי עד אפסי לעומת המחיר בקריאות ופשטות של הקוד.

אם כברכ עסקינן בזוטות, יש מקום לשיפור הקריאות של הקוד ע"י שימוש ב += , השמטת ה toString ושימוש במציין סוף שורה ג'נרי שאינו תלוי בפלטפורמה. כל הנקודות האלה הינן זוטות אולם כל אחת מלמדת משהו על עבודה נכונה עם ג'אווה ועל הפילוסופיה מאחורי השפה.

[שניצל]

לפי דעתי אין צורך. בין כה הקומפיילר מחליף חיבור של מחרוזות בקריאה ל StringBuffer (וכל ההבדל בין StringBuffer ו StringBuilder הוא סינכרוניזציה)

הרווח בביצועים הוא מזערי עד אפסי לעומת המחיר בקריאות ופשטות של הקוד.

מסכים, בגלל זה אמרתי "יש אנשים" ולא אני

יש כאלה שדווקא יאמרו ש-StringBuilder יותר קריא, כי ברור מראש שאתה יוצר מחרוזת ע"י שרשור של מחרוזות.