אז בjava9 לממשקים יהיו private methods

[TakeCtrl]

אז בjava9 לממשקים יהיו private methods

שאפשר יהיה לקרוא להם מdefault methods

לא יודע איך להרגיש בקשר לזה...
https://dzone.com/articles/more-pow...t&utm_medium=email&utm_campaign=dd 2017-04-08

 

[BravoMan]

אתה צריך להרגיש משהו בגלל פיצ'ר של שפה?

בגדול, עוד לא פגשתי שפה שאנשים מרוצים ממנה.
&nbsp
שפה פשוטה - אנשים בוכים שהיא עניה, מישהו כאן לא מזמן בכה למה ב-Java צריך לכתוב פונקציות set ו-get וכמה זה מכוער לאומת properties של #C.
&nbsp
שפה עשירה - אנשים בוכים שהיא מסובכת מידי, ואין אף אחד שבאמת מבין אותה, ראה ערך ++C.
&nbsp
בזמנו, היו אנשים שטענו שירשוה מרובה, היא דבר סטני, וטוב שאין אותה ב-Java.
עכשיו, מישהו כנראה החליט ש-Java חלשה מידי, ולמעשה פתחו פתח לקבל הורשה מרובה בלי להודות שפתחו פתח להורשה מרובה.
&nbsp
יכול להיות שזה שימושי.
אבל כך או כך, אתה לא חייב להשתמש בזה, אז אל תתרגש יותר מידי.

 

[Miki Watts]

אז זה כבר לא interface,זה הפך להיות אפקטיבית מחלקה אבסטרקטית

 

[Guy Yafe]

אז הוסיפו. נו שוין.

אישית אני לא חושב שהדבר הזה שימושי. אני בטוח שיש אחרים שיחשבו שזה שימושי.
לJAVA כמו לכל שפה יש יתרונות וחסרונות, רובם מסומנים ככה בגלל דעה אישית ולא כעובדה מוגמרת.
&nbsp
&nbsp

 

[יבגניי34]

מחד נראה מוזר. מאידך מבין את הצורך, או ״צורך״

ב #C לא פעם מממשים ממשק ע״י מחלקה אבסטרקטית רק כדי לדחוף איזה מימוש דיפולטי, וזה מוביל ל bloatware ו״אבסטרקטיזיס״.

כמו שאמרו כבר ״נו שויין״, די מסכם את הנושא...

 

[nocgod]

בחיים שלי לא הרגשתי צורך לדחוף ב#C מימוש ברירת-מחדל בממשק

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

זה בדיוק ההבדל בין ממשק לבין מחלקת בסיס

 

[יבגניי34]

ואולי ״לא הרגשת״ כיוון שתחביר השפה אינו מאפשר זאת.

 

[TakeCtrl]

לא "הרגיש" אבל דחפו לו משהו מקביל בכל מקרה..

זה מה שנקרא "extension method" כן, אני יודע שזה לא אותו הדבר, אבל
גם C# וגם java היו צריכים פתרון בשביל לממש functional programming (ב .net זה הLinq בjava זה streams, הם היו צריכים להוסיף לכל הממשקים שלהם מתודות שמקבלות פונקציות Callback בשביל לעשות סינון , חיפוש וכו'... ולשניהם הממשקים היו כבר ציבוריים ומומשו בכל העולם.
לכן כל אחד יצר מנגנון שגרם לו ללכת עם ולהרגיש בלי, כלומר להרחיב ממשק ולא לשבור תאימות אחורה.
&nbsp

 

[יבגניי34]

אבוי לא ניתן להשתמש extension methods למימוש דיפולטי של ממשק

 

[nocgod]

מה קשור?

ext methods זה פשוט מתודה סטאטית בקלאס סטאטי שמקבלת כפרמטר ראשון את הארגומנט עליו היא מתכוונת לעבוד ועוד פרמטרים לאחר מכן, כלומר:
א. זה מתודה עבור instances בלבד
ב. זה מתודה שלא יכולה לגשת לmembers פרטיים או מוגנים של מחלקה
ג. זה מתודה שיש לה את סדר הresolution הכי נמוך כשמחפשים מתודה
ד. היא איננה מרחיבה את interface אם איננה טעונה ונמצאת ב resolution scope.

או במילים אחרות זה פשוט syntax suger לכל אותם מיליוני מחלקות ה helper שיש בקוד שעושות בדיוק את זה, עוזרות לך להחביא לוגיקה לתוך מתודות ועדיין לקרוא להן בצורה יפה ככה שהקוד שלך אומר "מה לעשות, לא איך".

איך קישרת את זה למימוש המעוות של java לממשקים עם מתודות פרטיות, מתודות סטטיות עבור ממשק, ומימוש דיפולטיבי שיכול לקרוא למתודות של הממשק?

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

 

[TakeCtrl]

אין שום דבר רע בbackwards compatibility

כן, צריך לעבוד יותר קשה, אבל אני לא חושב שאנשים צריכים להתעקם ולעשות שינויים בקוד קיים רק בשביל לעבור לגרסה חדשה. במיוחד מוסדות כבדים כגון בנקים וביטוח שהם הלקוחות העיקריים של java שגם ככה לא מתלהבים משינויים.
&nbsp
אני לא חושב שאפשר לקרוא לזה syntax sugar, בניגוד לbuilder pattern (ומימושיו בhibernate criteria), מתודה סטטית צריכה להראות ככזו, וextension method "מתחזה" למתודה שהיא חלק מהממשק, בערך כמו שstatic import בjava, גורם למתודה סטטית ממחלקה אחרת להתחזות כאילו היא חלק מהמחלקה הנוכחית.
בdefault method לפחות אתה יודע איפה הוא נמצא, בextension אתה יכול להגדיר אותו בכל מקום שבא לך. ואם Microsoft או מישהו אחר מממשים את המתודה קודם הם שותים לך את המימוש בלי להודיע.
שתבין, אני לא כל כך נגד, השתמשתי בextension method, כדי ל"הרחיב" את log4net כדי שיקבל מתודות debug עם למבדה (במקום if debugEnabaled קראתי אפילו מאמר על זה).
&nbsp
אבל בסופו של דבר קישרתי את זה לdefault methods כי בלי 2 הדברים האלה (בJava ו .net), אני לא רואה דרך שהיו מצליחים להוסיף את כל מתודות הstream בjava וLinq ב.net בלי לשבור את כל הממשקים, זה נראה פשוט כל כך בולט לעין שנראה לי שהאחד לא היה ממומש בלי השני. כלומר לא היו מוסיפים default אילו Streams לא היו בתכנון.

 

[nocgod]

זה ש2 דברים נראים לך דומים

רחוק שנות אור מלהגיד שהם דומים.
א. אין שום דבר רע בbackwards compatibility - זה מעולה, מצד שני לממש פיצ'רים חדשים בצורה עקומה כי חייבים חייבים לשמור תאימות לגרסא בת 10 שנים, נראה לי פחות רציונלי. מה גם - אף אחד לא בא לבנקים או לחברות הביטוח ומכריח אותם לעדכן ל java8, שישארו בג'אווה 3 בכיף שלהם, שום דבר לא יקרה להם אם הם לא יעדכנו.
ב. קראתי לזה סוכר סינטקטי כי זה מה שזה - זה סוכר סינטקטי, בקוד IL זה הופך להיות קריאה סטטית לכל דבר. יותר מזה אם תעשה decompile לקוד אתה תראה שזה קריאות סטטיות לכל דבר.
ג. נכון ל ext method יש את רמת ה resolution הכי נמוכה ואם מישהו ידחוף מתודה עם אותה החתימה היא תיקרא ולא המתודה שלך. זה בעיה אם אתה לא מבין מה מטרת ה ext method. אתה לא משחרר סיפריה עם ext method, אתה עושה את זה רק כדי להעשיר interface קיים בפונקציונליות שאפשר לטעון לפי צורך לקוד שלך באמצעות חבילת הרחבה.
ד. נכון 2 הדברים פיתרונות דומים, אך שתי הדברים שונים בין אם זה במימוש ובין אם זה בשימוש.
ה. אתה יכול להגיד שגם java וגם #C מממשים generics, ולעין בלתי מזויינת, זה נראה אותו הדבר. אם תחקור את העיניין תראה שהם מממשים אותו בצורה שונה לחלוטין ושבג'אווה בruntime אין generics באמת. אז זה נראה דומה - בפועל שונה לחלוטין.

 

[TakeCtrl]

התכוונתי שמטרת הפתרונות נראית זהה, לאפשר הרחבת interface

ללא שבירתם, המימוש שונה.
&nbsp
המון דברים נראים שונה בdecompile ,כלפי מפתח כשהוא קורא למתודה מתוך ממשק הוא חושב המתודה היא חלק מהממשק.
אגב, קרוב לוודאי שגם default methods יכולים להטעות אני לא כל כך ממהר להשתמש גם בהם.
&nbsp
בקשר לחברות ביטוח, אולי לא עבדת שם, אבל Java לא חי לבד,, בדרך כלל הוא מגיע עם websphere ודומיו, ולאלו יש חוזה החזקה שיכול להגמר ובהחלט יכול להכריח אותך לשדרג לwebsphere, ואם אותו websphere מעלה את הגרסה המינימלית של java שלא תהיה תואמת לשלך, תמצא במלכוד.
&nbsp
כן, אני יודע שgenerics הם רק בקוד, ובjava כ(בדיוק בגלל סיבת תאימות אחורה), וקרוב לוודאי שמי שעובר מ.net לjava והפוך בלי לדעת כלום על generics של השני יכול להיות מופתע, אבל שוב, אם הם היו מכריחים (ופה מדובר עוד ב1.4 הגרסה שאפילו גוסלינג שונא) אנשים לעבור ל5 , הכניסה של זה הייתה הרבה יותר איטית (אם בכלל)

 

[nocgod]

ועכשיו אנחנו חוזרים למה שפתחתי אית

עושים דברים הזויים ועקומים כי
* מפחדים לשבור
* רוצים לשמור תאימות לאחור 10-15 שנים למרות שזה רק דופק את השפה יותר
* חדירה של תקנים חדשים איטית
* במקרים רבים פרוייקטים ישנים בכלל לא מתקדמים לגרסאות חדשות
ופרוייקטים חדשים סובלים מ"אבות אכלו בוסר ושיני בנים תקהינה"

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

 

[TakeCtrl]

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

הייתי בחברת ביטוח שהיה להם CTO שעל כל דבר קיים אמר שהוא "חרא" שצריך לזרוק ולכתוב מחדש עד שזה הפך למשהו הזוי ואבסורדי.
שנית, דווקא בגלל שכן יש תאימות אחורה, יש פחות חשש להתקדם לגרסא חדשה כי לא לשנות קוד קיים בלחץ, אלא לאמץ אותו בהדרגה.
אז נכון, זה יותר איטי, אבל java עדיין מאמצת תקנים, חדשים, התהליך עצמו של JCP מבוצע בשיתוף עם הקהילה.
הפרוייקט אצלנו התחיל נראה לי לפני כמה שנים טובות בגרסה 5 ואילו היינו חייבים לשנות קוד עבור כל גרסה חדשה תאמין לי שההחלטות לשדרג היו הרבה יותר איטיות.

 

[אוהב להתווכח]

יש סיכוי ש\זה יגיע גם ל-C#

https://www.infoq.com/news/2017/04/...l&utm_term=0_cacef7f3d3-95824727c9-1206172701

 

[nocgod]

אוי ווי...

גם ככה השפה נותנת מספיק כלים כדי לכתוב קוד מעוות, עכשיו גם זה...