שאלה ב design

[rubens1]

לא לא. ממש לא לצערך.

אלוהים אדירים. שפה בלי מספרים בלתי מסומנים. מי לעזאזל חשב על הרעיון הנוראי הזה? שפה בלי templates - איך לעזאזל הם מצפים מאיתנו לתפקד? שפה שבה אין type checking על הvector. יאכס. שפה שבה מייצגים לך מספרים בצורה של אובייקטים, כדי שיתאימו לכל מיני collections וmethod invokations. פיכס.

 

[אוֹריארד]

ריח של בורות...../images/Emo4.gif

 

[rubens1]

כן... באמת ריח סרוח..

אז בוא תספר לי איפה הבורות שלי..

 

[voguemaster]

will take too long...

 

[ChipsMan]

הכל טוב ויפה..

אבל מצד שני היא הרבה יותר בטוחה.. אתה יכול להכריח את מי שמשתמש במתודות שלך לעטוף אותן ב-try/catch ולתפוס את כל ה-exceptions שאתה רוצה. אתה לא יכול לחרוג ממערך ולצאת מזה בשלום בלי לחטוף exception. בד"כ יש שם מנגנוני Garbage collection מאד מתקדמים ומהירים ובד"כ מפנים זיכרון יפה מאד. (נראה לי שהיום עובדים על שילוב של Generational עם Fully concurrent mark and sweep.. למי שמכיר). בנוסף, בזמן ריצה מתבצע profiling של הקוד. הקוד מתקמפל משפת המחסנית של ה-JVM לקוד native שרץ על המעבד שלך עם האופטימיזציות שצריך. (ע"ע hotspot). דברים שקומפיילר רגיל צריך לנחש בזמן קומפילציה ה-JVM יודע בזמן ריצה. זה מאפשר יצירת קוד מאד מהיר. הדבר היחיד שבאמת חסר לי בג'אווה זה חוסר בהעמסת אופרטורים

 

[rubens1]

Exceptions...

דוגמה מושלמת למה שאני כל כך שונא בשפה הזאת. בגלל שאתה חייב לעשות Catch לכל הexceptions שיכולים להזרק, נוצרים 2 מצבים אבסורדים למדי: א. אתה מוצא קוד שכל פונקציה שבו מוצהרת כthrows exception. ב. אתה מוצא קוד שבו פעולות שגרתיות שיכולות להכשל ואתה מעדיף להתעלם מהשגיאה תופסות 5 שורות, והקוד גם נראה זוועה. הGarbage collection זה אחד הדברים הכי זוועתיים שאי פעם נתקלתי בהם. חוסר השליטה הזאת בהקצאות זכרון, פשוט הופכת את הג'אווה לכלי גרוע במיוחד. אז נכון, הקוד שלי לא משתמש בdelete יותר, אבל הוא מוצף בכל מיני Object = null; Object.Pointer = null; לגבי profiling - עם כל הכבוד ליכולת של ג'אווה לנתח את עצמו ולמצוא איפה הקוד לא יעיל, ג'אווה מעודדת חוסר יעילות, וגם גורמת לחלק גדול ממנה. תוכניות בג'אווה רצות לאט יותר. לעזאזל, אם הVisual Studio הייתה נתקעת כל שניה, כמו שהJBuilder 9 נתקעת, מיקרוסופט היו אוכלים על זה הרבה מאוד קש. העמסת אופרטורים? מה פתאום! זה רע! זה גורם למתכנת לחשוב! להשתמש בכלים שיש לו לטובתו! זה שכמה משתמשים שלא מכירים את השפה מספיק טוב גורמים לבאגים על ידי הfeatures האלה, זאת ההוכחה הניצחת שלא צריך לתת כוח למתכנתים, אלא לנטול אותו באכזריות מבין ידיהם.

 

[אלדד28]

exceptions הן דוגמה מצוינת למשהו

שיש ב- ++C ולא נמצא בשימוש מספיק. JAVA מהבחינה הזו הרבה יותר טובה, כי היא שומרת על התוכניתן. אני לא אתפלא אם באיזשהו שלב יעודכן הסטנדרט של ++C להתנהג באותה צורה.

 

[voguemaster]

זוועתי ??

אני מודה שיש בעיות מסוימות עם GC, במיוחד שאין עליו שליטה ממשית

. לעומת זאת, הוא לא דבר זוועתי בכלל. יש בג'אווה כמה דברים שאני אוהב אישית: 1. רפרנסים חכמים - הם סוג של הכלאה בין רפרנס של ++C לבין מצביע. 2. ספריות ו-API די עשיר (למי יש כח עכשיו לחפש ספריות לכל מיני דברים...) 3. זמן פיתוח קצר. עכשיו, למה זמן הפיתוח בג'אווה קצר ? זה קשור לפוינטרים החכמים שלה ול-GC. ראשית, אין שום קשר בין לכתוב object = null לבין GC. זה די נדיר שאתה צריך ידנית להסיר את כל ההצבעות אל אובייקט מסוים. תראה דבר מעניין: רוב האובייקטים שאתה עובד איתם הם אובייקטים זמניים יחסית, ולוקליים. כל מיני דברים כמו String וכד'. הרפרנסים אליהם מתים בסוף הפונקציה שמשתמשת בהם. אין שום לעבוד בד"כ עם object = null אלא אם כן יש לך משהו מאוד מאוד ממוקד שאתה צריך לעשות, וגם אז, לא בטוח שאי אפשר אחרת.

 

[אלון וינשטיין]

כתיבת קוד גרוע לא קשור לשפה

מתכנת שכותב קוד java שכל (או אפילו חלק קטן, למען האמת) מהפונקציות שלו מוגדרות כ throws Exception לא מכיר/מבין טוב את השפה, וכנראה יתכנת קוד מכוער/גרוע בכל שפה. צריך לדעת להשתמש ב Exceptions באופן מושכל בjava. מעטים הם המקרים, אם בכלל, בהם בקוד שנכתב נכון נזרקת Exception שאין ערך לחייב את הקורא לפונקציה לתפוס אותה. בהרבה מקרים שיש חשש למצב כזה אפשר לעבור לשימוש ב RuntimeException. אני מרבה למשל להשתמש ב java ב return codes ולא זורק exception על כל דבר קטן. אני מעדיף להשתמש בהן רק למקרי קיצון, שם הן מוכיחות את עצמן ככלי יעיל ושימושי. ומי אמר שצריך לעבוד ב JBuilder ב java?

 

[אלדד28]

כל הדברים שאתה מדבר עליהם

הם חסרונות בכיוון אחד, ויתרונות בכיוון אחר. בדיוק כמו קיום פוינטרים ב-++C. זה גם חסרון וגם יתרון. אותו דבר מספרים מסומנים וכו'.

 

[voguemaster]

מה טוב במספרים מסומנים ??

 

[אינגולמו]

כל הכבוד!

הצלחת להכניס את כולם לדיון חסר טעם לדעתי, ואולי גם לא כ"כ בכוונה. ולמה? כי לשאול שאלה כזו בפורום תכנות הוא עניין בעייתי בפני עצמו. ולמה? כי השאלה שלך מטעה אנשים. מה הכוונה בדיוק "מבחינה עיצובית, אבל לא מבחינה טכנית"????? שים לב שנושאי הדיון גלשו לאמ-אמא של הטכניקה: NAMESPACES, הערות כמו "אבל ב-JAVA אי אפשר לעשות את זה", וכו' וכו'. ולא סתם: כי לדון בתיאוריות עיצוב תוכנה הוא עניין קצת רחוק מלעצב תוכנה. אין משמעות לשאלה כמו שלך בשפות תיכנות *אמיתיות*, אלא רק בתיאורטיות שאולי נוכל להמציא לצורך הדיון. אבל כמו שבטח כבר הבנת, פתרונות כמו NAMESPACE ומתודות סטאטיות ב-C++, מחלקות UTILS ב-JAVA ומי-יודע-מה עוד בשפות אחרות, הם כולם פתרונות טובים לשאלה שלך הן בהיבט הטכני והן בהיבט העיצובי. באופן כללי, טיב העיצוב *מבחינה פרקטית* תלוי בין היתר במה נהוג בסביבה שבה אתה מפתח. אם ב-JAVA נהוג לפתור בעיה בצורה "עיצובית" מסויימת, ב-C++ יכול מאוד להיות שנהוג לפתור אותה אחרת. נושא ה-TEMPLATES הוא היבט עיצובי שלם וייחודי לשפת C++, ודנים בו בספרות המקצועית באופן תיאורטי וטכני כאחד. כנ"ל לגבי גישת ה-JIT של JAVA. תוכניתן טוב יכיר, מן הסתם, כמה דרכים שונות לעצב/להבין-עיצוב-של פתרונות מסויימים. אני אישית משתמש הרבה ב-C++, ותפיסת העיצוב שלי לבעיה שהצגת, היא שימוש ב-NAMESPACE *או* במחלקה עם מתודות סטאטיות (אין למעשה הבדל כי מחלקה היא NAMESPACE). הייתי משתמש במחלקה כאשר יש מספר פונקציות מצומצם בעלות נושא משותף ספציפי מאוד וקרוב מאוד, וב-NAMESPACE, כאשר מדובר בכמות גדולה של פונקציות או בפונקציות בעלי נושא רחב יותר. למה? כי ברוב הספריות הסטנדרטיות, זה מה שנהוג. הקוד שלי, במקרה כזה, "ידבר טוב יותר" לתוכניתן C++ אחר (אבל ידבר פחות לתוכניתן JAVA). זו דעתי. לסיכום: אפשרויות העיצוב שלך הן רבות. חקור את "מנהגי" העיצוב בשפות הפופולריות (נכון לשנה האחרונה: C++, JAVA) והתאם אותן לבעיה שלך. אני בטוח שתוכל למצוא עיצוב מתאים לבעיה שלך בכל שפה שלא תבחר.