בואו נתחיל!

היררכיית הטיפוסים של קוטלין

בקוטלין, האב הקדמון של כל האובייקטים הוא Any – המקבילה של Object בשפת ג'אווה.

כך נראה אובייקט ה Any (השמטתי את ה comments):

אולי אתם שואלים את עצמכם היכן המימוש של המתודות? מדוע הוא לא הוגדר כ Abstract?
אני מניח שהמימוש נעשה ברמת ה runtime – ויש החרגה ברמת הקומפיילר למחלקה הספציפית הזו.

המחלקה Any מכילה גם כמה extension functions (החשובות שבהן: apply, let, run, also) – המוגדרות בקבצים אחרים. נדון בקונספט ה extension function ובמתודות הללו ספציפית – בהמשך הסדרה.

האם Any הוא באמת האב הקדמון של כל המחלקות בקוטלין?
לקוטלין יש את מערכת ה Nullable, שבעצם אומרת ש:

ולכן באופן לוגי האב הקדמון של כל האובייקטים בקוטלין הוא ?Any. אין קובץ המכיל קוד מקור של ?Any – אך ניתן להחזיר אותו מפונקציה, או לרשת ממנו.

ניתן לשרטט סכמה של היררכיית הטיפוסים בקוטלין בערך כך:

קשר לוגי משמעו שהקומפיילר מכיר בקשר, ואפשר באמת להתייחס לקשר בקוד, אך לא תמצאו קוד כזה בקוד המקור של קוטלין: אין קוד מקור למחלקה ?String היורשת מ ?Any.

הזכרנו כבר שבקוטלין אין פרימיטיביים, ולכן כל ה wrappers (כמו Int) – יורשים בעצם מ Any.

Nothing הוא מקרה קצת מיוחד – אותו גם הזכרנו: Nothing מתאר ביטוי שלעולם לא יסיים evaluation. למחלקים Nothing לעולם גם לא יהיו instances.

מכיוון שכל ערך יכול להיות מוחלף ב Nothing, אבל אף ערך לא יורש ממנו, נהוג לצייר את Nothing בתחתית ההיררכיה – אבל זה תיאור מטאפורי בלבד.

השימוש ב Nothing עוזר לסמן לקופיילר מקרים ש"הקומפיילר לא צריך לדאוג מהם". למשל, המימוש הבא של EmptyList (זהו ה pattern של NullObject – למי שמזהה):

מקור

הורשה בקוטלין

בפוסט הקודם כבר הצגנו הורשה, אך לצורך הדיון – בואו נפתח שוב בדוגמה פשוטה:

1. עלי להצהיר על המחלקה open, אחרת תהיה לי שגיאת קומפליציה שתצביע על המחלקה SpecialPerson שיורשת אותה. מחלקות הן final בקוטלין, כברירת מחדל. זו גישה הגנתית המספקת פחות הפתעות מהורשה לא צפויה.
2. כנ"ל לגבי פונקציה: כל הפונקציות הן final כברירת מחדל – ויש "לאפשר" לרשת אותן במפורש.
3. חובה להגדיר override בפונקציה שדורסת מימוש של מחלקת-האב, בניגוד לאנוטציה Override@ בג'אווה – שהיא רשות.
4. התחביר של הורשה הוא : – כמו ב #C. סוגריים נדרשים כדי לדעת אם להפעיל את בנאי-ברירת-המחדל של מחלקת האב – או בנאי אחר.

המילה השמורה final עדיין קיימת בקוטלין. היא משמשת אותי במקרה ואני רוצה "לסגור" מתודה פתוחה, ולא לאפשר לדרוס אותה בהמשך ההיררכיה:

1. הגדרתי את המתודה a כ final במחלקה SpecialPerson. לולא ההגדרה – הגדרת ה "open" מהמחלקה Person – הייתה ממשיכה הלאה במורד ההיררכיה.
2. …ולכן – יש לי שגיאת קומפליציה בבואי לדרוס אותה.

מחלקות חתומות (Sealed Classes)

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

1. אני מגדיר את המחלקה InsuranceResult כ sealed (במקום Open). זה יתיר רק למחלקות שהוגדרו באותו הקובץ (private scope) – לרשת ממנה.
2. הנה יצרתי 2 מחלקות פשוטות. העימוד בא להדגיש את הקשר.
3. שימוש נפוץ הוא בכדי להחזיר סט סגור של ערכים. למשל: פעולה של אישור ביטוח שיכולה להסתיים בהצלחה (תשובה מסוג אחד – Approved) או בכישלון (תשובה מסוג אחר – Denied).
   1. המחלקות Denied, Approved, ו InsuranceResult – הן public, וניתן להשתמש בהן מכל מקום.
4. הנה הקוד שמקבל את התשובה, גם הוא – פשוט ואלגנטי.

מחלקות מופשטות (abstract), וממשקים (interfaces)

בקוטלין יש מחלקות מופשטות (abstract):

1. עצם ההגדרה של מחלקה כ abstract אומרת ש:
   1. המחלקה יכולה להכיל members מופשטים (abstract).
   2. לא ניתן ליצור instances ממנה.
2. הנה פונקציה מופשטת. פונקציה מופשטת היא "פתוחה" (open) בהגדרה.
3. אפשר גם להגדיר פונקציות קונקרטיות – עם מימוש. הם יהיו "סגורות" כברירת מחדל.
4. כשאני דורס פונקציה מופשטת, עדיין עלי להצהיר על דריסה בעזרת override.
5. יש לי שגיאת קומפילציה, מכיוון וניסיתי לרשת פונקציה ממחלקה מופשטת, בלי המילה override. מוסיפים override – ויש שגיאה נוספת. מה הפעם?
   1. כברירת מחדל פונקציות (ומחלקות) הן final. עלי לשנות את ה פונקציה collect ב InventoryItem להיות open – ורק אז הכל יסתדר.

ממשקים בקוטלין הם דיי דומים לג'אווה – עם כמה הבדלים קטנים.

החל מג'אווה 8, ממשקים יכולים להחזיק מימוש קונקרטי למתודות.
יוצרי קוטלין טוענים שהם חשבו על הרעיון קודם (הושפעו מה Traits של סאקלה)! בכל מקרה – התוצאה דומה:

1. הנה הגדרה של ממשק פשוט: יש בו פונקציה אחת מופשטת (ללא מימוש), ואחת קונקרטית – עם מימוש.
2. בממשקים של קוטלין ניתן להגדיר תכונות, אבל ללא state (חייבים להגדיר getter, ולא יהיה  backing field מאחורי התכונה).
   1. שימוש אפשרי לתכונות על ממשק – היא כחלופה לקבועים על הממשק – שאין בקוטלין.
3. הנה אני יוצר אובייקט שיורש מ Person ומממש את הממשקים Happy ו Shiny. סדר ההגדרה של הממשקים / מחלקת אב – לא משנה.
4. אני מחויב לדרוס את המתודות המופשטות של הממשקים, כמובן – ולספק להן מימוש קונקרטי.
5. מה קורה כאשר לכמה ממשקים שירשתי מהם, יש פונקציה קונקרטית עם חתימה זהה (בדוגמה שלנו: reflect)? כיצד לא נגררים לבעיות של הורשה מרובה?
   הפתרון של קוטלין אלגנטי: הקומפיילר מחייב אותי לממש מחדש את הפונקציה.
   1. שימו לב שאם החתימה היא שונה (פרמטרים שונים) – אז אין בעיה, ואני לא אחויב לממש מחדש.
6. super הוא מילה שמורה המתייחסת ל super type שלי.
   שנייה! יש פה בעיה: הקומפיילר לא יודע איזה מימוש של reflect אני רוצה לקבל: של Shiny או של Happy? זו שגיאת קומפליציה שתתרחש רק במידה ויש קונפליקט / דו-משמעות.
   1. הפתרון הוא לבאר לקומפיילר מה אני רוצה, בעזרת התחביר הבא: (super<Happy>.reflect(s 
      , קרי לספק למילה השמורה super את הטיפוס הספציפי שאני בוחר להתייחס אליו. כשאני משתמש בתחביר הזה – הקומפליציה תקינה, וקריאה ל ()reflect של S.H.Person – תפעיל את המימוש הקונקרטי של Happy.

השאלה המתבקשת עכשיו, היא: מה ההבדל בין מחלקה מופשטת בקוטלין, לממשקים?
אם אפשר להגדיר פונקציות קונקרטיות על ממשק – מה בעצם הצורך במחלקה מופשטת? האם מחלקות מופשטות הן לא "מיותרות"?אפשר לאפיין ארבעה הבדלים בין מחלקות מופשטות לממשקים:

1. במחלקה מופשטת כל ה members הם final כברירת מחדל (כמו כל מחלקה) – בממשק הם open, ולא ניתן להגדיר אותם כ final.
2. בממשק לא ניתן להגדיר members כ internal. ורק פונקציות קונקרטיות ניתן להגדיר כ private. בקטנה.
3. מחלקה יכולה לרשת ממשקים רבים – אך רק מחלקה מופשטת אחת – זה כנראה ההבדל הכי חשוב.
4. זה מעט מורכב: ממשק לא יכול להחזיק state, אחרת עלולים להיווצר קונפליקטים במימוש-מרובה.
   לכן, השפה מציבה כמה מגבלות על תכונות (properties) שהוגדרו בממשקים:

1. בממשק אני יכול להגדיר val או var:
   1. val – ניתן להגדיר לו getter בלבד, או להשאיר את התכונה מופשטת (abstract).
   2. var – התכונה תמיד תהיה מופשטת. ניסיון להוסיף getter יגרור לשגיאת קומפילציה.
2. מכיוון שהתכונות של הממשק Koo הן מופשטות – המחלקה המממשת חייבת לממש את התכונות הללו: x ו y (להלן override), ואז עלי לנקוט באחת מהגישות הבאות:
   1. 1. אני יכול להציב בתכונות ערך התחלתי (מה שאי אפשר לעשות בממשק)
      2. אני יכול לממש getter/setter בעצמי.
         1. הערה: val הוא readonly – ולכן אין צורך ב setter.
      3. אני יכול לדרוס את התכונות ב primary constructor. הערכים שהוגדרו שם "יחביאו" את אלו שהוגדרו על הממשק.

מחלקות מקוננות (Nested Classes)

בקוטלין יש 2 סוגים של מחלקות מקוננות:

1. Minion היא מחלקה מקוננת של Father, סתם כך.
   כברירת מחדל מחלקה מקוננת היא "סטאטית" כלמר – מחלקה עצמאית לכל דבר שרק חיה ב namespace של המחלקה שעוטפת אותה.
   1. יוצרים אותה בנפרד.
   2. היא לא יכולה לגשת לתכונות / פונקציות של מחלקת האב.
2. בצורה השנייה, משתמשים במילה השמורה inner, בכדי לחבר את המחלקות ברמת המופעים (instances)
   1. לא ניתן ליצור מחלקה פנימית ללא החיצונית. ביצירת מופע של המחלקה החיצונית – נוצר גם מופע, מקושר, של המחלקה הפנימית.
   2. אם יש התנגשות בשמות, ניתן להשתמש ב qualified this" expression" – להגיע למחלקת האב. דומה מאוד ל OuterClass.this בג'אווה.
      1. ניתן גם להשתמש ב qualified super, בתחביר ()super@Father.foo – בכדי לגשת לפונקציה של המחלקה ממנה האובייקט החיצוני יורש.

מה קרה ל static ובן-אל?

בקוטלין ביטלו את המילה השמורה static. אין קונספט של מתודות סטטיות במחלקה.
מצד שני, יש קונספט של singleton מובנה בשפה – בעזרת המילה השמורה object:

1. בעזרת המילה השמורה object, אנחנו בעצם מגדירים מחלקה – ומייד יוצרים לה מופע.
   1. אובייקט הוא מופע יחיד (singleton). השימוש הנפוץ בו הוא ליצירת Factory או אובייקט שמכיל איברים סטטיים – המשותפים לכולם.
   2. ניתן להגדיר על האובייקט תכונות, ופונקציות – אבל לא בנאים. הרי: לא יוצרים אותו. המופע נוצר בעצם ההגדרה.
   3. ניתן לרשת ממחלקה אחרת / לממש ממשקים.
2. אם היינו רוצים להגדיר קבוע בג'אווה היינו משתמשים ב static final. בקוטלין קיימת במילה השמורה const שמצביעה לקומפיילר שמדובר בערך שידוע בזמן קומפילציה. השימוש ב const היא הצהרה שזהו ערך סטטי שלא הולך להשתנות. המשמעות:
   1. אי אפשר להציב תשובה מפונקציה, קרי ()const val x = foo – זו שגיאת קומפילציה.
   2. אי אפשר להוסיף getter – הרי getter יוכל "לשנות את הערך, ע"י החזרה של ערך אחר", ולעולם בעתיד לא יהיה ניתן להוסיף getter. זו אולי התכונה בעלת הסמנטיקה העמוקה ביותר.
   3. אפשר לאתחל את התכונה רק ערכים פרימיטיביים (מספרים, מחרוזות), ולא אובייקטים – אחרת, ייתכן אי אפשר להבטיח שכלום לא ישתנה.
   4. בפועל: מאחורי const לא יהיה backing field.

שונות

ארכז כאן עוד שני נושאים קטנים שקשורים למחלקות, אבל לא השתלבו בטבעיות בנושאים הנ"ל.

late init

לפעמים יש לי תכונה מסוג var שאני עומד להציב בה ערך בתהליך האתחול של המערכת – אך לא מהרגע הראשון.
הקומפיילר, המגן עלי בפני nulls – יצעק, ולא יוותר. "מה פתאום ערך לא מאותחל?!"
בואו נראה דוגמה קלאסית:

1. הפתרון ה"פשוט" הוא להציב ערך null בשדה – עד האתחול ה"אמיתי".
   1. בקוטלין זה דיי מעצבן, כי אז עלי להפוך את כל הטיפול באותו משתנה ל nullable – התעסקות מיותרת.
2. הפתרון: להוסיף modifier בשם lateinit, המורה לקומפיילר: "אחי, עלי! המשתנה הזה יאותחל לפני שיקראו לו". השימוש ב lateinit מאפשר קוד נקי יותר, ללא טיפול ב nullability.
   1. מצד שני: אם טעינו (והטענו את הקומפיילר) – תיזרק שגיאת …UninitilizedProperty.
      שם השגיאה, מכוון למהות הבעיה, יותר טוב מאשר לקבל סתם Kotlin)NullPointerException).
3. כאשר מגדירים lateinit, השדה של התכונה (במקרה שלנו: repository2) ייחשף לקוד הג'אווה. זוהי החלטה תכנונית של מקסום התאימות לג'אווה.
   1. אפשר למנוע את חשיפת השדה ע"י ה annotation האופציונלי: field:JvmSynthetic@

ה runtime של קוטלין קובע ערך null בתכונות lateinit – לסמן לעצמו שהן עדיין לא אותחלו. לכן – לא ניתן להגדיר lateinit לתכונות מטיפוס שהוא Nullable.

גישה לאובייקט ה Class

בג'אווה ניתן לגשת למחלקה של אובייקט ע"י הקריאה object.class – זהו בעצם אובייקט מטיפוס <Class<T, הנוצר ב מנגנון ה reflection ומתאר את תכונות (metadata) המחלקה: שם ה package, שדות, וכו'.

ספריות שונות משתמשות ביכולת הזו, למשל: JUnit:

בקוטלין, ניתן לגשת לאובייקט ה reflection המתאר את המחלקה בעזרת הקריאה object::class – זהו אובייקט של ספריית ה runtime של קוטלין מסוג KClass (על הכוכבית – בהמשך הסדרה).
הוא מכיל מתודות ותכונות reflection של קוטלין, למשל companionObjectInstance – המחזירה מצביע ל companion object, אם קיים.

רוצים לקבל את אובייקט הג'אווה המתאר את המחלקה שלנו (אובייקט ה Class, שהוא בעל מבנה שונה מאובייקט ה KClass)? – קראו ב object::class.java.

ברוב הפעמים דווקא נדרש לאובייקט-המטא של קוטלין. למשל:

זה תלוי מה הספריה עושה איתו. זה עניין של ניסוי וטעייה.

סיכום

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

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

שיהיה בהצלחה!

הגדרת מחלקה פשוטה

בואו נתחיל עם המחלקה הפשוטה ביותר האפשרית בקטולין:

פשוט, לא?
האמת שזה דיי דומה למחלקה ריקה בג'אווה: פשוט אם אין body – אז אין צורך בסוגריים מסולסלים.

מה השימוש במחלקה ריקה?

לא הרבה.
אפשר לייצר ככה custom exception או Marker interface או Marker Annotation (בתחביר מקוצר הרבה מג'אווה).

טוב, עכשיו נתחיל יותר ברצינות:

1. בקוטלין לא ניתן להגדיר שדות (fields) למחלקה. במקום זאת – מגדירים תכונות (properties). מה זה אומר?
   1. השורה שלנו תגרום לקומפיילר לייצר גם שדה, וגם accessor methods לשדה הזה.
      1. כאשר כותבים  בקוטלין – הגישה לתכונה (property) תעשה בעזרת person.age – כאילו זהו field שהוא פשוט public.
      2. כאשר כותבים בג'אווה – הגישה לתכונה של מחלקה הכתובה בקוטלין תעשה בעזרת ()person.getAge  ו ()person.setAge – כמקובל.
   2. מאחורי כל תכונה (property) באמת קיים שדה (field). לעתים – לא יהיה בשדה הזה בכלל שימוש. נראה דוגמה בהמשך.
   3. הסיבה מאחורי הוספת properties לשפה, היא כנראה Item 14 בספר "Effective Java" – המזהיר בפני חשיפת שדות שאז לא יהיה ניתן לשנות, לבקר, ולהגביל את הגישה אליהם. "אחרי שנחשפו – זהו!… התלות קיימת וזו יכולה להיות עבודה קשה להסיר אותה…"
   4. בקוטלין נתנו לנו את האפשרות להוסיף custom getter/setter בכל יום שנצטרך – אבל בלי הסרבול של לכתוב getters / setters בעצמנו, בכל פעם, כי "אולי בעתיד יהיה צורך".
      להיות עם – ולהרגיש בלי.
2. בקוטלין יש primary constructor, וייתכן שיהיו secondary constructors.
   ה primary constructor מוגדר באותה שורה עם הגדרת המחלקה.
   1. מגדירים אותו בעזרת המילה השמורה constructor.
   2. מגדירים אלו פרמטרים הוא יקבל.
   3. אם לא מגדירים primary constructor אזי נוצר default primary constructor – ללא פרמטרים.
3. ה init block נקרא בכל יצירה של instance של המחלקה, והוא בעצם משמש כגוף הפונקציה של הבנאי הראשי (primary constructor) – אם צריך כזה.
   1. כל התכונות של המחלקה צריכות להיות מאותחלות. אם נסיר את השורה "age = 0" – נקבל שגיאת קומפילציה.
      הקומפיילר דורש שאנו נאתחל את התכונות באותה השורה (מה שנקרא initializer, כמו ב name) – או שנאתחל אותם ב init block / בבנאי הראשי.
4. הנה הגדרה של בנאי משני למחלקה.
   1. ההגדרה שלו נעשית בעזרת המילה השמורה constructor.
   2. מגדירים את הפרמטרים של הבנאי המשני.
   3. חובה להפעיל את הבנאי הראשי:
      1. או ישירות – ע"י קריאה עם הפרמטרים המתאימים.
      2. או ע"י קריאה לבנאי משני אחר – שהוא יפעיל את הבנאי הראשי.
      3. כאשר קיים default primary constructor – אין צורך ב ()this :.
5. הנה יצירת מופע של המחלקה בעזרת שימוש בבנאי הראשי.
6. הנה יצירת מופע של המחלקה – בעזרת שימוש בבנאי המשני.
7. הנה קריאה לתכונה – היא באמת נראית כמו קריאה לשדה בג'אווה – מה שהופך את הקוד למעט יותר "נקי בעין".

1. הצלחנו לפשט את המחלקה דרמטית, בעזרת הגדרה "נבונה" יותר של הבנאי הראשי.
   1. המילה constructor בשורת המחלקה, לתיאור הבנאי הראשי – היא אופציונלית, ואפשר לוותר עליה.
   2. אם מגדירים val או var על הפרמטרים של הבנאי הראשי – הרי זה שקול להגדרת תכונות בגוף המחלקה. הארגומנטים שנשלחו לבנאי – יאתחלו את התכונות הללו. קצר ונוח.
      יכולת זו שמורה לבנאי הראשי בלבד.
   3. השימוש ב default value בחתימה של הבנאי הראשי – ייתרה את הצורך בבנאי משני.
      1. במקרים לא מעטים, השימוש ב default values – יכול לחסוך שימוש ב Builder Pattern, ולחסוך לא-מעט קוד.
2. הנה ההרצה: אין שום שינוי, כי לא היה שום שינוי. הקוד שקול לחלוטין.

אמנם כך עדיף לכתוב את המחלקה, אך היה חשוב לי לעבור בדרך הארוכה – עבור הלמידה.

עוד קצת על תכונות (Properties)

בואו נחזור ונחדד עוד כמה דברים לגבי תכונות:

1. הגדרנו למחלקה תכונה בשם age – ודרסנו את ה getter. ממש דומה לתחביר של #C.
   1. כעקרון, כאשר דורסים רק שלפן (accessor) אחד, במקרה שלנו: getter, השלפן השני – עדיין קיים במימוש ברירת המחדל שלו. כלומר: ל age עדיין יש default setter.
   2. ספציפית במקרה שלנו, מכיוון ש age הוגדר כ val (כלומר "immutable") – לא ייווצר setter.
2. רק לצורך ההדגמה יצרתי תכונה מאוד דומה, אותה הגדרנו כ var. במקרה כזה, אנחנו מחויבים לאתחל את השדה של התכונה – גם אם לא יעשה בו שימוש לעולם (במקרה הזה: עם הערך אפס).
3. כאשר ה getter שלי הוא פשוט – אני יכול להשתמש בתחביר shorthand, בעזרת הסימן =.
   1. יכולתי להשתמש בתחביר shorthand גם עבור age.
4. אם אני לא רוצה שיגשו ל setter של התכונה – אני פשוט אגדיר אותה כ private.
   התחביר הזה אומר לקומפיילר: צור default setter – אך עשה אותו private.
5. הנה – סתם בשביל ההדגמה: אני יכול להשתמש ב setter של התכונה בתוך המחלקה.
6. אגדיר תכונה נוספת בשם nickname – אין לי בעיה לאתחל אותה בערך שנגזר מתכונה אחרת – name.
7. כאן מימשתי setter לדוגמה. ה getter ה default-י עדיין קיים וזמין.
8. מה קורה כאשר אנחנו רוצים, ב customer accessor שלנו לגשת לשדה שמאחורי התכונה?
   1. עושים את זה בעזרת המילה field.
   2. field היא מה שנקרא soft keyword, כלומר: keyword שקיים רק ב context מסוים. ממש כמו it – שראינו בפוסט הקודם.
9. בניסיון ההרצה, שלושת השורות הללו יגרמו ל compilation error.
   1. את לשלושת התכונות הללו: age, name, ו ageNextYear – לא ניתן לקבוע ערך מחוץ למחלקה.

Visibility Modifiers

בקוטלין, visibility ברירת המחדל היא תמיד public. יש שוני קטן בהגדרות כאשר ה visibility modifier מוגדר:

• בתוך מחלקה.
• ב top level, כלומר: עבור הגדרה של מחלקות, משתנים, או פונקציות שאינן שייכות למחלקה.

הנה ההגדרות:

• private 
  • יתנהג כמו ג'אווה בתוך מחלקה
  • יגביל גישה לאותו קובץ בלבד, אם השתמשו בו ב top-level.
• protected
  • יתנהג כמו ג'אווה בתוך מחלקה
  • לא ניתן להשתמש בו ב top-level.
• internal
  • היא נראות חדשה לקוטלין, שמגדירה אפשרות לגשת לכל מי שנמצא באותו המודול.
    • כיצד מוגדר מודול? ע"י תהליך הקומפליציה: קבצים שקומפלו ביחד.
      זה יכול להיות מודול של Maven, של Gradle, או מודול ב IntelliJ – למשל.
  • היא מתנהגת אותו הדבר בתוך המחלקה, וב top-level

בואו נראה קצת קוד:

1. הגדרתי את המשתנה כ private – לא יוכלו לגשת אליו מקובץ אחר.
2. הגדרתי מחלקה שהיא internal – זמינה רק בתוך ה module.
   1. כל המחלקות בקוטלין הן final – לא ניתן לרשת מהן, אלא אם מרשים זאת במפורש בעזרת השימוש ב open. אהבתי!
3. מה עושים כאשר רוצים להגדיר "שדה פנימי" בקוטלין? רק לשימוש המחלקה?
   – מגדירים תכונה שהיא private, ומשתמשים בה.
4. פה נראה שאולי עשיתי איזה טריק: הגדרתי getter ו setter על התוכנה – כך שאי אפשר לגשת ל accessors שלה. האם הפכתי אותה ל private?
   1. בפועל: אין תחביר כזה:
   2. הקומפיילר מתעלם מ get ומגדיר רק את ה default setter כ private.
   3. תראו למטה – אמנם הקוד מתקמפל, אבל אני בהחלט יכול לגשת ל someHiddenField ממחלקה אחרת. אופס!
5. הנה דוגמה תקינה ל default setter שהוא private. אפשר כמובן גם להגדיר custom setter באותו האופן.
6. ניסיתי להגדיר internal getter – אך קיבלתי שגיאת קומפילציה: ה getter של תכונות חייב להיות באותה נראות כמו התכונה עצמה. חשבו אילו בעיות יכלו להיות אם לא…
7. באופן הבא אני יכול להגדיר נראות (private) על primary constructor.
   כאשר אני משתמש ב visibility modifier על הבנאי – אני חייב להשתמש במילה constructor.
8. על השורה הזו אני מקבל warning בקומפליציה: ה class לא הוגדר כ open – אז לא ניתן לרשת ממנו. אין טעם או משמעות להגדיר נראות של protected. צודק הקומפיילר.

Data Class

אחד הבזבוזים הגדולים של boilerplate code בג'אווה הוא ביצירה של data classes – מחלקות שכל תפקידן להחזיק כמות מסוימת של נתונים.

אני תמיד הייתי משתמש ב public fields, אבל יש כאלו שהקפידו על getters ו setters, וגם hashCode ו equals וכו'… הרבה קוד – עבור משהו מאוד סטנדרטי.

בקוטלין אפשר להגדיר data class, מחלקה שמספקת לנו:

• תיאור כוונות ברור: המילה data מצביעה בבירור על הכוונה מאחורי המחלקה.
• מימוש ל ()equals(), hashCode(), clone, ומימוש default-י וסביר לחלוטין של ()toString.
  בערך כל מה שמחלקה כזו צריכה.

שני Data Classes שימושיים שמסופקים כחלק מהשפה הם Pair ו Triple, המאפשרים לנו להעביר זוגות או שלשות של פרמטרים.

אלו באמת רק Data Classes. למשל, הנה המימוש של Triple:

Enum Class

בדומה לג'אווה, לקוטלין יש enum… class. בואו נראה כיצד הוא נראה:

1. הנה דוגמה ל enum פשוט. כל איבר הוא בעצם אובייקט – מופע של המחלקה.
   1. זהו אחד המקרים המעטים בהם צריך בקוטלין לכתוב יותר קוד מאשר בג'אווה: "enum class" במקום "enum"  😏
   2. מכיוון שהאיברים הם אובייקטים, אני יכול להרחיב אותם, למשל: לדרוס פונקציה של המחלקה (או להוסיף פונקציה חדשה). הפונקציות הללו שייכות לאובייקט, ולא למחלקה!
2. אני יכול הוסיף גם פונקציה למחלקה, שתהיה זמינה לכל אחד מהאובייקטים ב enum.
3. יש מקרה דיי נדיר בו עלי להשתמש בנקודה-פסיק בקוטלין:
   1. אם הוספתי ל enum class פונקציות, הקומפיילר יבקש עזרה לדעת היכן נגמרה רשימת האיברים, והיכן מתחילה המחלקה. ההפרדה מסומנת בעזרת נקודה-פסיק.
   2. שימו לב שב TriColor לא היינו צריכים להוסיף נקודה-פסיק (אבל יכולנו – זה תקין).
4. מכיוון ש BLUE הוא אובייקט – כאן תופעל, באופן טבעי, הפונקציה ()toString.
5. לכל enum class יש את הפונקציה ()valueOf, המחפשת איבר ע"פ השם שלו.
   1. ניתן להציץ בקוד המקור של ה Abstract Enum Class כאן.
6. לכל אובייקט ב enum יש 2 תכונות מובנות:
   1. name – (ששווה לשם האיבר), בחוסר תלות מ ()toString.
   2. ordinal – שהוא האינדקס של האיבר.
7. תכונה אחרונה חשובה של enum היא הפונקציה ()values – המחזירה מערך של האיברים. לצורך הפלט – המרתי את המערך לרשימה.
8. אני יכול לשנות את המחלקה ולהוסיף לה תכונות דרך הבנאי הראשי.
   הנה ל TwoColor הוספתי תכונה בשם value – שיש לכל אחד מהאיברים שלה.

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

כרגיל, ננסה ללמוד עוד קצת על הדרך:

1. הנה כמה קל להשתמש בקוד ג'אווה: אני מבצע import מתוך java.lang.Math לפונקציית החזקה (power).
   בג'אווה, בכדי לייבא מתודה הייתי צריך להדגיש: import static. בקוטלין – ויתרו על התחביר המיותר.
   שווה לציין שכל שלכל קובץ של קוטלין מתבצע מאחורי הקלעים import לשורה של חבילות: *.java.lang וכמה חבילות של קוטלין.
2. כאשר מספר הוא עשרוני, הקומפיילר אוטומטית מניח שהוא מסוג Double. לא צריך לכתוב d בסוף המספר (אבל כן צריך לכתוב F אם אתם רוצים שיוגדר Float).
3. כך נראית פונקציה – שוב: מאוד דומה ל Go, מאוד "מודרני".
   שימו לב לטבעיות בשימוש בפונקציה pow שהגיעה מספריה בג'אווה.
4. הדרך להפעיל (invoke) פונקציה – היא כמו בג'אווה.
5. זו הדרך הפשוטה להציג רק 2 ספרות עשרוניות למספר – בעזרת פונקציית format של ג'אווה.
6. אני יכול לקרוא לפונקציה תוך כדי שאני מציין את שמות הפרמטרים כמו שהוגדרו בפונקציה (ואז סדר הארגומנטים לא משנה).
   זה אולי קריא יותר, אבל ה IntelliJ מוסיף תגיות מאוד דומות בכל מקרה (כיביתי אותן כרגע).
7. זו הדרך לבצע formatting לאלפים + 0 ספרות לאחר הנקודה – שוב, בעזרת פונקציית format של ג'אווה.

Nullable Types

בוודאי אתם מכירים שה Exception הנפוץ ביותר בג'אווה הוא NullPointerExcpetion.

כמו שפות מודרניות אחרות, יוצרי קוטלין החליטו להגדיר את השפה כ "null-safe by default". כעיקרון, אין nulls, אלא אם אתם מתירים אותם.

1. זו תהיה שגיאת קומפליציה. מה פתאום לקבוע ערך null? אין מצב!
2. אם אנחנו מגדירים ש y הוא מסוג Nullable String – אז אפשר לקבוע בו ערך null. בסדר.
3. גם זו שגיאת קומפילציה: השתגעתם? לקרוא למתודה ()length למשהו שעשוי להיות null? אנחנו לא רוצים nullpointerException!
4. פה הקומפיילר חכם: אם כבר בדקתי שהערך איננו null – אז יאפשרו לי לקרוא למתודות על האובייקט ה nullable.
5. דרך אחר לעשות זאת, להשתמש באופרטור ?. במקום . – שמגן עלי בפני nullPointerException.
   אם y הוא null – אזי תוצאות כל הביטוי תהיה גם היא null.
6. מה קורה עם מחלקה שאני מביא מג'אווה? בג'אווה – כל האובייקטים הם Nullable.
   אתם רואים שאני צריך לבנות מבנה דיי מורכב (ולא מעניין) על מנת להגן על עצמי מ NullPointerException.
   החלטה תכנונית של שפת קוטלין היא לא להגן עלי בכוח בפני אובייקטים של ג'אווה – כי כך אני רגיל. ההגנה ברמת הקומפילציה היא רק בפני אובייקטים של קוטלין שהם Nullable.
7. בכל זאת, קוטלין מספקת לי תחביר מקוצר ובטוח לעבודה עם אובייקטים שהם Nullable. התחביר הזה תופס גם לאובייקטים של ג'אווה, וגם לאובייקטים של קוטלין שהם Nullable (ואולי יש להם פונקציה שערך ההחזרה שלה הוא Nullable).
   במקרה הזה, מכיוון ש ()getExtID מחזיר null (נניח), כל הביטוי יוערך כ null – ולא ייזרק NullPointerException.
8. לקוטלין יש כמה כלים לעבוד עם רשימות שחלק מהאיברים בהן עשוי להיות null.
   גישה ראשונה היא השימוש בפונקציה let שתפעל רק אם הערך הוא לא null.
   אפשר להשתמש ב let גם ללא קשר לרשימת איברים.
9. גישה שניה, היא להשתמש בפונקציה / פילטר בשם ()filterNotNull, כלומר: להשאיר רשימה הכוללת רק איברים שאינם null.
10. אני יכול לבדוק אם משתנה הוא null ולהגיב בהתאם.
11. או בגלל שזו פעולה שכיחה, להשתמש באופרטור ה 😕 (נקרא Elvis Operator) – בכדי להשיג בדיוק אותו הדבר בכתיבה מקוצרת.
12. אם אני ממש מתעקש, אני לומר לקומפיילר: "עזוב אותי באמאשלך! אני אסתדר עם ה null-ים שלי בעצמי", בעזרת אופרטור ה .!!.
    1. שימו לב שאת האופרטור הזה אפשר להפעיל רק על משתנים שהם immutable (למשל: val) – אחרת, יכול תאורטית thread אחר להיכנס בין "שורות" ההפעלה שלי – ולשים בו null.
       1. אופס!, חטפתי KotlinNullPointerException.

הנה הפלט:

ערכי החזרה מיוחדים

שימו לב לחבר'ה הבאים:

2. ניתן להגדיר את אותה הפונקציה כ Unit בצורה מפורשת.
3. הפונקציה fail היא מסוג Unit, אבל בעצם היא לעולם לא תחזיר Unit – כי תמיד היא זורקת Exception (שימו לב שבקוטלין לא משתמשים ב new).
4. ניתן להגדיר פונקציה שלעולם לא תגיע ל return – כבעלת ערך החזרה מטיפוס Nothing.

את Nothing לא ניתן להציב במשתנה – זו בעצם הערה לקומפיילר.

5. כאן נקבל שגיאת קומפליציה מסוג Conflicting declaration – הקומפיילר לא יודע איזה טיפוס להגדיר ל data:
Int – בגלל Zoo?
או אולי Any (ה root בהיררכיית האובייקטים בקוטלין, כולל null) – בגלל ש fail הוא מטיפוס Unit?

6. במקרה הזה הקופיילר רגוע: מ ()gail לא יכול לחזור ערך (הוא מסוג Nothing), ולכן data יוגדר כטיפוס Int.

מעניין אולי לציין ש null הוא singleton מטיפוס ?Nothing.

default value ו vararg

1. אני יכול להגדיר בפונקציה פרמטרים עם ערך ברירת מחדל – למשל: cores.
2. אני יכול לקרוא לפונקציה עם כל הארגומנטים (ה annotations הם של ה IDE).
3. אני יכול לקרוא לפונקציה ולהשמיט את הארגומנט – ואז לקבל את ערך ברירת המחדל.
4. הנה הגדרתי פונקציה לחישוב ממוצע ה CPU utilization במכונה – ע"י חישוב הממוצע של ה cores.
   שימו לב שניתן להשתמש בכתיב מקוצר (=), אם הפונקציה גוף הפונקציה הוא ביטוי (expression) בודד – גם אם אין ערך החזרה. הגדרה כזו נקראת shorthand function.
5. אני יכול גם להגדיר מספר משתנה של פרמטרים – בעזרת המילה vararg (המקבילה של … בג'אווה).
   המשתנה core הוא מטיפוס <Array<out T  – אסביר את הנושא של out, כשנגיע ל Generics.אם יקראו ל printStats עם 2 פרמטרים – הפונקציה הראשונה תופעל.
   אם ל printStats עם מספר שונה של פרמטרים – הפונקציה השנייה תופעל.

התוצאה:

פונקציות מסדר גבוה

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

1. הנה אנחנו מגדירים פונקציה בשם profile המקבלת פונקציה אחרת (func) כפרמטר.
   התחביר הוא סוגריים עם רשימת משתנים, חץ (<-) וערך החזרה.
   מעבר לכך, זהו פרמטר לכל דבר.
2. בכדי להוסיף ערך מוסף כלשהו, השתמשתי בפונקציית ה profiling של ג'אווה, המחזירה את הזמן הנוכחי בננו-שניות.
3. הפעלה של הפונקציה func נעשית בצורה טבעית למדי.
4. עכשיו אגדיר 2 פונקציות דומות המתאימות בחתימה לפרמטר func של profile: מקבלות 2 מספרים שלמים – ומחזירות ערך של מספר שלם
5. כעת אני סקרן לדעת איזו פונקציה יעילה יותר מבחינת ביצועים!
   כך אני מפעיל את הפונקציה "הגבוהה" profile:
   הקומפיילר צריך לדעת שאני רוצה לשלוח רפרנס לפונקציה ולא להפעיל אותה, את זה עושים בעזרת האופרטור :: – המחזיר reference לפנוקציה.
   הקפדתי על ארגומטים עם ערך זהה, על מנת לא להטות את בדיקת הביצועים 😉
   אם אני רוצה רפרנס למתודה של אובייקט, התחביר הוא object::method.
6. מה קורה כאשר אני רוצה להגדיר חתימה של פונקציה שלא מחזירה כלום?
   אם אגדיר רק (Int) – הקומפיילר יתעלם מהסוגריים ויניח שמדובר בפרמטר מסוג Int.
   עלי לציין ערך החזרה מסוג Unit (כפי שראינו מוקדם יותר בפוסט) – ואז הקוד יתנהג כמצופה.

אלף ננו-שניות הן מיקרו-שניה (ולא מילי-שניה, לא לבלבל!).
הממ… משהו מוזר לי בזמנים של הפונקציה add – הייתי מצפה לכ 50,000 ננו-שניות (5 הפעלות של פונקציה) ומטה (אופטימיזציות של הקומפיילר)…

Lambda Expressions

בואו נסתכל שוב על הפונקציות add ו addFast שלמעלה. עבור שימוש חד פעמי – הייתי צריך להגדיר פונקציה, מה שלוקח עוד קצת מקום אבל בעיקר – מנתק את הקוד מההקשר.

לא היה נחמד יותר לכתוב את גוף הפונקציה inline?

1. הנה אני יכול לכתוב את הפונקציה inline, כ anonymous function. זה התחביר – ללא שם. זה עדיין לא מאוד אלגנטי.
2. יותר אלגנטי יהיה לכתוב את אותה הפונקציה inline כ lambda expression. זה התחביר.
3. מכיוון שהקומפיילר יודע מה החתימה של profile – זה מיותר לציין לו טיפוסים על הפרמטרים, ולכן ניתן לכתוב את הפונקציה בצורה קצרה יותר.
4. חשוב לציין שאם אני עושה extract variable ל lambda expression, והיא כבר לא inline – הקומפיילר לא יידע להסיק את הטיפוסים של הפרמטרים – ויש לציין אותם בחזרה.
5. לצורך ההסבר, נעבור לעבוד עכשיו עם פונקציה דומה ל profile בשם profileOne, המצפה לפרמטר אחד בלבד.
   שימו לב שהחלפתי את סדר הפרמטרים בפונקציה, כאשר func הוא הפרמטר האחרון. מייד אסביר מדוע זאת היא הקונבנציה ב higher order functions בקוטלין.
6. כאשר יש פרמטר יחיד לפונקציה, לא צריך להגדיר אותו. אפשר להשתמש בצורה מקוצרת המדלגת על ההגדרה (<- num) ישר לגוף הפונקציה. אם לא הוגדר שם משתנה – ההתייחסות אליו תהיה כ it.
   זה יכול להיות קיצור נחמד, אבל הייתי ממליץ לכם להימנע ממנו כאשר יש פונקציות מקוננות – אז זה נהיה מבלבל.
7. הנה הסיבה מדוע הקונבנציה בקוטלין היא שהפונקציה תהיה הפרמטר האחרון: אם ורק אם הפונקציה היא הפרמטר האחרון, אפשר לכתוב את גוף הפונקציה מחוץ לסוגריים.
8. למה זה טוב? זה שימושי אם אתם רוצים לייצר משהו שדומה ל DSL (יש עוד מה להרחיב בנושא בפוסטי המשך).
   למשל: הגדרתי את הפונקציה enhance (שאולי מוסיפה לוגים, בדיקות אבטחה, ניטור, וכיוצ"ב) ואז אני פשוט שולח לה קוד. זה דומה מאוד ל DSL.
9. אשנה קצת את ה layout של הקוד בכדי להדגיש: אתם יכולים להגדיר פונקציות שלכם, שנראות "כמו" מילה בשפה. כמה מבלבל הוא לראות enhance שכזה (מבלי להכיר את קוטלין) – ולא למצוא בגוגל מה הוא עושה 😏

הנה דוגמה פשוטה עבור ההסבר.
למשתנה n, שנמצא באותו ה closure עם הלמבדה – אני יכול לגשת.
למשתנה m, שנמצא בפונקציה עוטפת, אך לא בתוך ה closure – אני לא יכול לגשת.

משתנה שניגשנו אליו בתוך Closure לא "יוקפא הערך שלו" – כמו בג'אווהסקיפט, למשל.

לאחר הסרת השורה הבעייתית, הנה הפלט:

סיכום

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

האם סיימנו לכסות את נושא הפונקציות?
עוד לא.

יש עוד Local Function, Infix Functions, Inline Functions, Extension Functions – ואולי עוד שכחתי משהו.

בכל זאת, נראה לי שאפשר לשים את הפונקציות בצד לרגע – ולהתמקד בנושא יותר בוער ומסקרן: מחלקות.

הנה פוסט ההמשך.

שיהיה בהצלחה!