מבוא ראשוני לשפת Go, חלק 3 - תכנות בעזרת אובייקטים

פוסט זה הוא פוסט המשך לפוסטים:

• מבוא ראשוני לשפת Go, למפתחים ותיקים
• מבוא ראשוני לשפת Go - חלק ב' (מבנים בסיסיים, וקצת סגנון)

בפוסט זה נדון באספקט ה"אובייקטים" בשפה.


האם Go היא בכלל שפת Object-Oriented?

בכדי לענות על השאלה, בואו נבחן את שלושת התכונות העיקריות של שפות Object Oriented:

• הכמסה (encapsulation): מוגבלת. יש הכמסה ברמת החבילה, אך לא ברזולוציה קטנה יותר.
• ריבוי צורות (polymorphism): יש. בעזרת ממשקים - שנראה בפוסט זה.
• הורשה (inheritance): אין. משום סוג. הדרך ללכת בה היא composition.

50% התאמה לעקרונות הבסיס => Go איננה שפת Object Oriented.

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

אם אומרים על שפת JavaScript שהיא שפה "מבוססת אובייקטים" (היא לא מונחית-אובייקטים) כי יש בה אובייקטים, אך לא מחלקות - שפת Go היא רחוקה יותר מזה. ב Go ישנם "אובייקטים פתוחים", שרואים להם את השלד והאיברים הפנימיים: Structs ומתודות מקושרות.

הייתי מתאר את Go כשפה הנעזרת באובייקטים Object Aided Programming. היא מאמצת רק חלק מהרעיונות והחשיבה של תכנות מונחה-עצמים. האובייקטים הם כבר לא במרכז, אלא הפונקציות וה Structs - כשני אלמנטים נפרדים.

מקור: spf13

אובייקטים... מבנים ב Go

בואו נסתכל על קוד:

1. אנו מגדירים טיפוס חדש בשם Rectangle שהוא בעצם struct עם 2 שדות: width ו height.
1. שימו לב שאנו מתעדים את ה Struct ע"פ קונבנציית התיעוד של גו: ...a Rectangle is
2. בשלב זה אנו מגדירים מתודה, שמקבלת Rectangle ומחזירה int שהוא שטח המרובע.
1. בהגדרה, מתודה היא פונקציה עם receiver (לפעמים נקרא גם handler).
2. מתודה היא כזו שמשנה State (את זה של ה Struct = מבנה), פונקציה היא stateless.
3. מתודה ניתן להפעיל רק דרך רפרנס למבנה (כמעט אמרתי... אובייקט) כלומר (...)myStuct.myMethod, בניגוד לפונקציה שמפעילים ללא תלות, כלומר (...)myFunction.
3. הסוגריים המשונים הללו לפני שם המתודה הם ה receiver.
1. גו מחברת את הפרמטר של ה receiver (תמיד יש אחד) לשאר הפרמטרים של הפונקציה - כך שהוא תמיד יהיה ראשון. זה קורה מאחורי הקלעים. 
1. כלומר: החתימה של המתודה area היא בעצם, מתחת למכסה המנוע:
   area(r * Rectangle) int. 
2. הרבה יותר נוח לקרוא קונטקסטואלית את הביטוי ()rect.area, מאשר את (area(rect - ולכן ה syntactic sugar הזה.
2. הקונבנציה המקובלת היא לפרמטר של ה receiver באות הראשונה של הטיפוס (אות קטנה), או אולי קיצור של כמה אותיות קטנות. למשל: s או sb עבור stringBuffer.
   אם אתם מנסים לקרוא ל reference לטיפוס בשם גנרי - זה סימן שלא השתחררתם עדיין משפת התכנות הקודמת שלכם:
1. this (ג'אווה או #C?)
2. that (ג'אווהסקריפט, אולי?)
3. self (רובי?)
4. __self__ (פייטון! - תפסנו אתכם)
3. אם בקוד המתודה אתם לא משתמשים בפרמטר של ה receiver (בדוגמה שלנו: r)  - זהו smell שאתם זקוקים כאן ל function ולא למתודה.
4. אם בקוד המתודה אתם לא משתמשים ב fields פנימיים של ה struct (אלא רק מתודות אחרות) - ייתכן שעדיף להשתמש בפונקציה רגילה שמקבלת את ה struct כפרמטר.
4. הנה שימוש בקוד. אנו יוצרים שני מבנים: r ו r2.
   שימו לב ש r2 הוא מצביע ל Rectangle - כי השתמשנו במילה השמורה new.
5. אנו מדפיסים את תוכן ה Structs. הסימן & בהערה מציין שמדובר במצביע - אך שימו לב שאופן השימוש הוא זהה. בעזרת ה dot notation לא היינו צריכים לכתוב ()r2.area* מתוך ההבנה שזה פויינטר, וגם לא בקיצור כמו ()r2->area של ++C. הקומפיילר מזהה שהשתמשנו ב dot notation על מצביע, ומוסיף את ה * עבורנו, מאחורי הקלעים.
6. עכשיו בואו נענה על השאלה: מדוע ה receiver (סעיף #3) קיבל את Rectangle כפונייטר (קרי Rectangle*)? האם חובה להשתמש בפויינטר?
1. לצורך התרגיל נגדיר את המתודה Width (אות גדולה = שלפן) שמקבלת את Rectangle לא כפויינטר.
7. כאשר אנו משתמשים במתודה - אנו רואים שהערך לא השתנה: הצבנו 4, אך הערך נשאר 0.
   מדוע זה קרה?! בגלל שהעברנו למתודה העתק של r2 עליו התבצע השינוי. r2 עצמו לא השתנה.
8. הנה הבדיקה שאכן כך הדבר: כאשר אנו משנים את r2.width ישירות - הערך משתקף בהדפסה.

מפה עולה השאלה: מדוע בכלל לאפשר ליצור value receiver? מדוע הקומפיילר לא מגן עלינו ומחייב ש receiver יהיה רק pointer receiver? האם מתודה לא נועדה לשנות את ה state של המבנה המדובר?

התשובה היא לא-בהכרח.

• value receiver הוא שימושי כאשר מעבירים פונקציה, map, או channel (שהם כבר בעצמם מצביעים). ההעתקה של הערך יכולה להיות יותר יעילה מגישה לפויינטר שמצביע לאזור שאינו ב cache של המעבד.
  slice הוא גם מצביע, אלא אם המתודה עשויה להקצות ל slice מערך חדש - ואז יש להשתמש בפויינטר.
• value receiver הוא שימושי כאשר מדובר במתודה שהיא immutable, כלומר - העברה כ value (העתקה) מבטיחה שלא נוכל לשנות את ה state של ה struct.

בקיצור: אם אתם לא בטוחים - השתמשו ב pointer receiver. אם הזמן אולי תגלו את הצרכים ב value receiver גם כן.

אני רוצה שנייה לחזור למילה השמורה type ולהראות שאנו יכולים להגדיר aliases (כמו ב C) או מבנים שלא מבוססים בהכרח על struct. הנה דוגמה למבנה שמבוסס על slice:

הרכבת טיפוסים (Composition)

כפי שציינו, שפת גו מאמצת במלואה את ההמלצה "prefer composition over inheritance".
אם ניסיתם להימנע מהורשה ולהשתמש רק ב composition בשפות תכנות אחרות (אני ניסיתי בג'אווה) - בוודאי אתם יודעים שזה לא הדבר הכי אלגנטי שקיים:

• נניח שאנו רוצים לדמות מחלקה B שיורשת ממחלקה A.
• במחלקה B נוסיף שדה a שיכיל מצביע לאובייקט מסוג A.
• למחלקה B נוסיף את כל המתודות של מחלקה A, ובכל מתודה x נקרא בעצם ל a.x עם הפרמטרים שהעבירו לנו. זהו קוד boilerplate שמרגיש דיי מיותר - במיוחד ככל שלמחלקה A יש יותר מתודות.

בשפת גו יצרו תחביר של Composition שחוסך את ה boilerplate code. במבט ראשון - הוא נראה כמו הורשה, אך זו לא הורשה. מבנה B ש composes את מבנה A - לא יכול לגשת או להשפיע על מבנה A שלא דרך המתודות הציבוריות שלו. הבאגים שיכולים להיווצר בגלל תלות שכזו בהורשה - לא יתרחשו בצורת העבודה הזו. מצד שני צורת ה composition לא יכולה להשיג חסכון בקוד-כפול בכמה צורות שהורשה יכולה.

איך עושים זאת?

מבנה בשפת גו יכול להכיל fields שהם embedded (נקראים גם אנונימיים). יכולת זו נקראת Embedded Types.

1. אנו מגדירים את המבנה Person שמכיל שם, ומתודה sayHello.
2. אנו מגדירים את המבנה Student שמכיל Person ושם מחלקה, ומתודה sayHello.
3. שימו לב שבהגדרת ה Person לא ציינו שם של המשתנה (רק טיפוס). זהו embedded type שגורם להרחבה (extend). 
1. בפעולה זו אנו גורמים לכל ה fields והמתודות של Person להופיע ברשימת ה fields והמתודות של Student - דומה מאוד ל extend של מודול בשפת רובי. ה fields והמתודות עדיין נשמרים במבנה Person ומתנהגים כפי שהיו מתנהגים לו Person היה field מהמניין. נראה את ההתנהגות המדויקת מייד.
2. אם למבנה החיצוני (Student) יש מתודות / fields עם שם זהה למבנה הפנימי (Person) - הם תמיד יקבלו קדימות, ובפועל "יסתירו" את המתודות / fields של המבנה הפנימי.
3. ניתן עדיין לגשת למתודות של המבנה הפנימי בצורה מפורשת, קרי: student.Person.Name.
4. בשונה מהורשה, אם מתודה של Person תקרא ל field או מתודה שקיימים גם ב Student - היא תמיד תגיע ל field / מתודה ב Person, ואף-פעם לא ל Student. ניתן לומר ש invocation "הועבר" למבנה הפנימי (Person) ופועל עליו.
   חלק מהכוח של הורשה, בוא בכך שמחלקה היורשת מחליפה התנהגויות שמשפיעות גם על המתודות של מחלקת האב. התנהגות זו עלולה לגרום לבאגים מתסכלים, אם כי היא גם מאפשרת דפוסי-עבודה שיכולים לחסוך לא-מעט קוד.
4. הנה אנו יוצרים מופע של המבנה Student, ובתוכו את המבנה של Person. שם ה field שמחזיק את המבנה הפנימי הוא כשם הטיפוס של אותו מבנה. הבחור שלנו, ג'ון, נרשם באקדמיה בצורה לא מוסברת בשם "פופה".
5. תזכורת: ברשימות של איברים בגו יש להוסיף פסיק גם לאחר האיבר האחרון. זה מקבל על הוספת / הסרת איברים ללא שבירת הקומפילציה.
6. הנה אנו מדפיסים את student, ורואים כיצד הוא מיוצג בזיכרון - כמבנה מקונן.
7. כאשר אנו קוראים ל sayHello אנו מגיעים למתודה של המבנה החיצוני בהכרח (יש לה קדימות). הערך של שדה Name הוא זה של אותו המבנה.
8. כאשר אנו קוראים ל sayHello של Person בצורה מפורשת - אנו מגיעים למתודה של המבנה Person. הערך של שדה Name הוא זה של אותו המבנה, קרי Person.

ממשקים (Interfaces)

ממשקים הם הכלי בשפת Go לריבוי-צורות. ממשקים נפוצים בשפה הם io.Reader ו io.Writer שמסתירים מהקוד שלנו את פרטי המימוש הקונקרטי שאנו עובדים איתו (למשל: אמצעי קלט/פלט - דיסק, רשת, מבנה בזיכרון). מי שמגיע משפת ג'אווה, בוודאי מורגל לממשקים דומים. ממשק מפורסם אחר הוא error, המאפשר לנו להתייחס לכל השגיאות, אם אנו רוצים - באותה הצורה.

הבדל חשוב של ממשקים בגו מ"הקלאסיקה של ה OO", היא הרעיון שהם מבטאים:
ב OO מלמדים אותנו לחפש קשר של is-a או לפחות a-substitute-of בין הממשק ומי שמממש אותו, ושפות שונות מספקים כלים שונים לאכוף שאובייקט באמת רשאי למממש ממשק מסוים.

הגישה של גו היא גישה של Duck Typing שאומרת כך: "אם זה נראה כמו ברווז, ומשמיע קול של ברווז - אז זה ברווז!"

Duck Typing. לצורך העניין - זה יכול להיחשב כברווז.

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

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

גישת ה Duck Typing אם כן, מציגה tradeoff עם יתרונות וחסרונות - אולם זו גישה מקובלת ושנחשבת בהחלט סבירה. בשפת פייטון גישה זו הוכיחה את עצמה כישימה, גם בפרספקטיבה של זמן.


בואו נראה כיצד משתמשים בממשקים בקוד:

1. אנו משתמשים במילה השמורה type בכדי להגדיר טיפוס מסוג ממשק בשם statusReporter, המכיל 2 מתודות. 
2. אנו עכשיו מגדירים פונקציה שמקבלת statusReporter כפרמטר, ומבצעת עליה פעולה כלשהי - בהתבסס על מתודות של הטיפוס (Status ו LastErrors).
3. הנה הגדרנו איזה מבנה (=~אובייקט) שיש לו, במקרה או לא במקרה - מתודות עם חתימה זהה.
4. אנחנו יכולים לשלוח כל טיפוס שעונה לתנאי הממשק - כפרמטר לפונקציה printStatus שהגדרנו.

מבט מתקדם על Interfaces בשפת Go

עד כאן הכל נראה פשוט. אם אתם מגיעים מג'אווה / #C, אתם בוודאי אומרים לעצמם: "זהו: את העניין של ממשקים ב Go - כבר הבנתי!".

קחו עוד מעט אוויר. נותרו עוד מספר נקודות שעליכם לדעת על interfaces בגו בכדי לא-להסתבך איתם. התבוננו על דוגמת הקוד הבאה:

1. אנו מגדירים interface בשם HelloSayer.
2. אנו יוצרים מבנה בשם מר זאב, העונה לממשק (עם value receiver).
3. אנו יוצרים מבנה בשם גברת נץ, העונה לממשק (עם pointer receiver).
4. אנו מאחסנים 2 זאבים (מצביע, ומופע קונקרטי) ו2 נצים (גם מצביע ומופע קונקרטי - שתי האפשרויות הרלוונטיות) - בתוך slice מטיפוס HelloSayer. עצם ההשמה גורמת ל upcasting של ה references ל ממשק.

מה זה משנה אם יש לנו value receiver או pointer receiver?

האם בכלל לא צריך להתאים בין הערך ששולחים ל receiver?!

התשובה היא שמקרים A-C יעבדו בצורה תקינה, אך מקרה D יגרום לשגיאת קומפילציה "SayHello has pointer receiver" - שגיאה שבוודאי תתקלו בה בעבודה שלכם בגו, שגיאה שהיא קשה להבנה ללא הרקע המתאים.

מדוע דווקא מקרה D הוא זה שנכשל?

האם נחליף את הביטוי D ב "{}Hawke&", כלומר נשלח מצביע למבנה - הדברים ייסתדרו? (כן)

מדוע זה עובד כך?

יש יותר מדרך אחת להסביר זאת, אני אבחר בהסבר של הברירות שהיו למתכנני שפת Go - נראה לי שזה האופן הפשוט ביותר להסביר זאת.

בגדול אנו רואים שניתן לשלוח למתודה עם value receiver גם מופע (A) וגם פויינטר (C), אך למתודה עם pointer receiver ניתן לשלוח רק פויינטר (B).

שפת גו מנסה:

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

כאשר שולחים מצביע ל value receiver הקופיילר יכול לתקן זאת בקלות - ולשכתב את הקוד כך שישלח את הערך עליו מצביע הפויינטר. מי שכתב את המתודה מצפה לקבל עותק - וזה מה שהוא קיבל.

אם הקופיילר יתערב בשליחה של מבנה קונקרטי ל pointer receiver ויהפוך אותו למצביע, הוא מטעה את אחד הצדדים: או שהמתודה תניח שיש לה פויינטר ותבצע שינויים שיתעלמו מהם (כי מה שהועבר הוא עותק), או שמי ששולח ערך מניח שלא יכולים לשנות לו את הערך (הוא לא שלח פויינטר) - אך פתאום הערך יישתנה.

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

{}interface

הטיפוס {}interface הוא הממשק שאינו מכיל שום מתודות. ע"פ Duck Typing - מי מספק ("מממש") אותו? כולם!

זה אומר שזהו טיפוס-על שמייצג את כל הטיפוסים בשפה. ניתן להשוות אותו לביטוי *void (הידוע כ generic data pointer) בשפת C, אם כי {}interface הוא בטוח יותר לשימוש.

אילו טיפוסים ניתן להעביר בעזרת {}interface? האם אפשר להעביר int?
בואו נראה את דוגמת הקוד הבאה:

אפשר!

• האם {}interface מאפשר dynamic typing בשפת Go?
• לא. יש לו טיפוס סטאטי ומוגדר היטב. אפרט מייד.
• מהו, אם כן, הטיפוס של i בדוגמה לעיל?
• הטיפוס הוא {}interface. גו מבצעת type conversion על 1 ל {}interface, ואז חזרה בהדפסה.
• האם אפשר להחיל את הכלל הזה גם על מערך / רשימה? כלומר: להעביר int[] כ {}interface[]?
• לא. ניתן להעביר int[] כ {}interface (כי הוא טיפוס בשפה - slice) - אך הוא שונה מהותית "מערך של טיפוסים". אם רוצים לבצע את ההעברה יש לעשות עבודת העתקה ידנית.

interface בשפת גו הוא בעצם סוג של פויינטר כפול. ניתן לתאר אותו כמבנה (הדמיוני) הבא:

מצביע ראשון: interface-table (מסוג itab) - מבנה המכיל metadata של הטיפוס (שם הטיפוס, הגודל שלו בזיכרון) ואת רשימת המתודות המשויכות לטיפוס הזה.
מצביע שני: data - הכתובת בזיכרון מה מאוחסנים הנתונים. "200" עבור int או רצף התווים של struct מסוים.

הנה pitfall בשפה שניתן להיתקל בו:

1. נגדיר קבוע שמגדיר האם אנו אוספים נתונים ל BI או לא.
2. נגדיר את buf מטיפוס Buffer. הטיפוס Buffer מספק את הממשק io.Writer.
3. אם אנו במצב של איסוף נתונים - ניצור את ה buf, אחרת - אין טעם.
4. פונקציית Perform מבצעת איזו לוגיקה עסקית, וכותבת נתונים שנאספו ל io.Writer.
   יש הגנה במידה וה io.Writer שנשלח לה הוא nil.

מה תוצאת הריצה?

• אם collectData == true - התוכנה תתנהג כצפוי.
• אם collectData == false, אנו נקבל שגיאת panic שאומר כך: invalid memory address or nil pointer dereference. כלומר: ניסינו להשתמש במצביע שהוא nil.

איך זה קרה?
מה יכולנו לעשות טוב יותר??

התהליך שגרם לשגיאה הוא כזה:

• במידה ו collectData הוא false, אין השמה ל buf - והוא נשאר nil.
• כפי שאמרנו ממשק הוא לא מצביע. כאשר אנו קוראים ל perform סביבת הריצה מבצעת עבורנו type conversion מ Buffer ל io.Writer.
  out, שהוא מטיפוס ממשק io.Writer, מכיל עכשיו שני מצביעים: iTable שמצביע על Buffer (טיפוס + רשימת מתודות), ו data שהוא nil.
• בשלב #4 בקוד לעיל אנו בודקים אם out הוא nil, אבל הוא לא. הוא מבנה תקין מסוג ממשק שמכיל מצביע אחד לטיפוס, ומצביע שני שהוא nil.

באסה... מה עושים? איך לא נופלים בפח הזה?

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

אז מה עושים?

• לבצע בשלב #4 (וכל מקום אחר בקוד שמקבל רפרנס) בדיקה עמוקה יותר של nil. ג'אווהסקריפט מישהו? שיש בה גם null וגם undefined? - ממש לא! זו אופציה גרועה למדי.
• ניתן ליצור את Buffer בכל מקרה, ולבצע עבודה שלא נדרשת בכדי להימנע מטעויות. זו גם אופציה גרועה.
• הדרך הנכונה לתקן זאת היא להגדיר מראש (בשלב #2) את buf כממשק (קרי io.Writer ולא כ Buffer).
  buf יישאר nil עד שיושם לו ערך (שלב #3), ואז שני המצביעים של הממשק יתמלאו במקביל בערכים.

שימושים של {}interface

אז מה בעצם השימושים הפרקטיים של {}interface? כנראה שלא לעשות המרה מטיפוס ל {}interface, ואז מ{}interface לטיפוס בחזרה...

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

הנה פונקציה שממירה משתנה כלשהו (לא טיפלתי בכל המקרים) - לערך שניתן לשלוח לשאילתת SQL.

1. למשל: לא ניתן לשלוח nil ולכן הפכתי אותו למה שבסיס הנתונים מכיר - "NULL".
2. הביטוי (x.(int בוודאי נראה מעט מוזר. זהו ביטוי מיוחד בשפה הנקרא type assertion שבודק בו-זמנית שני דברים: ש x הוא לא nil, וגם ש x מתאים לטיפוס (או הממשק) שצוין - במקרה שלנו: int.
   הביטוי מחזיר שני ערכים כתשובה:
1. הערך השני ("ok") הוא bool שמציין אם ה assertion הצליח - כלומר: x הוא int שאינו nil.
2. הערך הראשון הוא הערך של x על פי הטיפוס שהגדרנו (קרי int). הוא יקבל ערך אפס - אם ה assertion אינו נכון.
3. Sprintf או כמו Printf, אך במקום לשלוח את הקלט ל default output הוא מחזיר אותו כמחרוזת.
4. עתה אנו עושים אותו תרגיל על bool, אך במקרה זה אנו רוצים לשמור את הערך.
   מדוע אנו משתמשים ב val? מדוע לא לשאול if x? - הקומפיילר לא יאפשר לנו ויכשיל אותנו בבדיקת טיפוסים. הוא יאמר שלא ניתן להגדיר תנאי if על {}interface. המשתנה val מוכר לקומפיילר כ bool.
5. ב Go אין ternary if (כלומר: : ?). חבל.
6. panic הוא סוג של Exception פנימי של סביבת הריצה של גו. שההנחיה היא לא להשתמש בו - אולי רק במקרים קיצוניים. האם יש במקרה זה צידוק להשתמש ב panic?
   מצד אחד: כאשר משתמשים ב type assertion מבלי לשמור את ערך ההחזרה השני ("ok") - גו תזרוק panic.
   מצד שני: זה לא המקרה אצלנו, ויש לנו בחירה מה לעשות.
   זהו דיון ראוי שאינני רוצה לנהל כרגע. בעיקר רציתי לציין את התנהגות ה panic של ה type assertion.

משהו היה מוזר לכם בדוגמה לעיל? כמובן - הקונבנציה בגו היא להימנע מ if else if! 

בשפה יש אופרטור דומה מאוד ל type assertion הנקרא type switch.

הנה דוגמת הקוד כאשר אנו משתמשים ב type switch:

1. הביטוי הוא דיי דומה, כאשר בתוך הסוגריים אנו מציינים את המילה השמורה type. ביטוי זה יכול לעבוד רק כחלק מ ל switch statement.
2. זה idiom מעט מבלבל: יכולנו לכתוב (val := x.(type ואז להשתמש בהמשך הפונקציה ב val - מה שהיה מפחית כנראה את הבלבול.
   בשפת Go ביטוי switch מגדיר scope משלו, scope שמתחיל שמתחיל מייד לאחר המילה switch. לכן ניתן להגדיר (x := x.(type, כאשר ה x הימני הוא זה שהוגדר ב scope הפונקציה, מטיפוס {}interface, וה x השמאלי הוא ב scope של ה switch בלבד - ויוכר כטיפוס שהוא בפועל. זה ה idiom.
3. המשך הפונקציה כנראה ברורה - וגם פשוטה יותר מהגרסה הקודמת.

סיכום קצר

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

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


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

----


לינקים רלוונטיים

Drill Down על ממשקים בגו:
פוסט של Jordan Relly (כיסינו את הרוב בפוסט) ופוסט של Russ Cox (ממש כיצד מומשו בשפה).

מבוא ראשוני לשפת Go - חלק ב' (מבנים בסיסיים, וקצת סגנון)

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

לולאות

1. פקודת for יכולה להכיל תנאי בינארי יחיד - ואז היא מתנהגת כמו while בשפת ג'אווה. ניתן להשמיט את התנאי בכלל - על מנת לקבל התנהגות "while true".
2. הצורה הקלאסית - גם היא נתמכת. אין צורך בסוגריים.
3. ניתן להשתמש בצורה הקלאסית עם השמה מרובה. הלופ הוא על המשתנה x, אך במקביל אנו מקדמים גם את הערך של משתנה y.
4. בלולאת for ניתן להשתמש ב break ו continue בדומה לג'אווה. שימו לב שאין צורך בסוגריים מסביב לתנאי ה if, אך יש צורך בסוגריים מסולסלים לתוצאת התנאי (אפילו אם זה ביטוי קצר). אני בעד!
1. אם יש לנו לופ מקונן, ניתן להגדיר Label ואז לציין בפקודת ה break - את הרמה אליה אנו רוצים לעשות break.
5.  במקום להשתמש בהשמה מרובה - השתמשתי כאן ב map (המקבילה של <?,?>HashMap). הטיפוס שבסוגריים מבטא את טיפוס ה key, והטיפוס אחריו - את טיפוס ה value.
6. השתמשתי ב range על מנת "לטייל" על ה map. אני מעוניין רק ב values ולא ב key, אז שלחתי את ה key ל bulk identifier.
7. שימו לב: הפקודה range תטייל על ה map בסדר מעט אקראי. זהו פיצ'ר של השפה שנועד להזכיר לנו של Map (או Dictionary)  - אין באמת סדר.

פונקציות

1. הגדרת הפונקציה main, שכבר מוכרת לנו. בשפת גו אין ל main פרמטרים או ערך החזרה (כמו ב C, או ג'אווה).
   המילה השמורה להגדרת פונקציה היא func. לא עוד function ארוך או def בפייטון שנשמע כמו "death". אהבתי! חבל שלא קיצרו עוד יותר וקראו לה fun...
2. לפונקציה יכול להיות ערך החזרה, הוא מוגדר מימין.
   למה מימין? האם זה לא קצת מוזר? הסיבה היא עבור מקרים בהם חתימת הפונקציה היא מורכבת:
1. הנה תראו את הפונקציה שמקבלת כפרמטרים "פונקציה שמקבלת 2 ints ומחזירה int" ו int, ומחזירה "פונקציה שמקבלת 2 ints ומחזירה int". לוגי, וקריא בצורה מפתיעה - לא?
2. הנה דוגמה שלילית בה הגדרנו את טיפוס ההחזרה בהתחלה (נניח, כמו בג'אווה). האם אתם מסוגלים לקרוא את זה בלי מאמץ ניכר?
3. הפונקציה יכולה לקבל כמובן כמה פרמטרים. אם הם מאותו טיפוס - ניתן לקצר.
4. ניתן לכתוב גם בכתיבה מלאה. float32 הוא 32 ביט - כך שלא צריך להיזכר כל פעם מהו "double".
5. ניתן להחזיר מפונקציה מספר ערכים. במידה ויש יותר מערך החזרה אחד - יש לשים את ערכי ההחזרה בסוגריים.
6. ניתן לתת שמות לערכי ההחזרה (למשל s1, s2). השמות הללו יוגדרו כמשתנים בפונקציה ולכן אינם יכולים לחפוף לשמות הפרמטרים. הגדרת שמות לערכי ההחזרה מאפשרת לנו להשתמש ב naked return שמחזיר את ערכי המשתנים הרלוונטיים. שימוש אפשרי הוא ערך שאפשר לקבוע בכל מקום בפונקציה, ולעשות return בלי לציין אותו במפורש (למשל error, אבל לא רק).
   הערה: השמות היא שימושיים רק ב scope של הפונקציה, ולא כערך החזרה / חתימה של הפונקציה.
7. פונקציה שמקבלת מספר לא מוגבל של פרמטרים נקראת variadic function. המשתנה שיכיל את "שאר הפרמטרים" מוגדר ע"י שלוש נקודות והטיפוס הרצוי (כמו varargs בשפת ג'אווה). בפועל זה יהיה slice של אותו הטיפוס (מייד נגדיר לעומק מהו slice), והוא חייב להיות הפרמטר האחרון בחתימה הפונקציה - כמובן.

ערכים בגו תמיד מועברים לפונקציה by value (כלומר: כעותק של הנתון). אם רוצים להעביר משתנה by reference - יש להשתמש בפויינטר (& בכדי לקבל פויינטר מערך, ו * בכדי להתייחס לערך שהפויינטר מייצג - כמו בשפת C).

פרימיטיביים מספריים בשפת גו

מערכים ו Slices

מערכים שפת Go הם כמו שאנו מכירים אותם משפת ג'אווה: הם מוגדרים לטיפוס מסוים (מערך של int, מערך של Person) ואורכם הוא קבוע. האיברים ממוינים ע"פ אינדקס שמתחיל ב 0.

Slices הם יותר כמו ArrayList - ניתן דינאמית להוסיף / להסיר איברים מהם.
כמו בשפת ג'אווה - Slices ממומשים על גבי מערך. בעצם ה slice הוא כמו View על ה Array:

מקור: הספר החינמי Build web application with Golang

מבנה הנתונים של Slice מכיל בעצמו:

• שם
• מצביע למערך
• טיפוס האובייקטים במערך
• offset
• length של ה slice

כל האובייקטים עצמם מאוחסנים בעצם רק במערך - לא ב slice. זהו גם מקור השם slice.

אם אתם זוכרים - כל הערכים מועברים בשפת גו by value. אם אתם רוצים להעביר reference - עליכם להעביר פויינטר.

Slices הם סוג של פויינטר. ההעתקה שלהם היא זולה (זה struct קטן עם 5 שדות) ולכן ניתן להעביר אותם בקלות "by value", אבל לקבל התנהגות, על מערך הנתונים, של העברה "by reference". שינוי של ערך ב Slice ישנה כמובן את הערך במערך - בו שמורים הנתונים. ניתן להחזיק כמה slices על גבי אותו המערך, כך ששינוי ערך ב slice אחד ישפיע על ערכים של slices אחרים מעל אותו המערך.

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

1. הדרך ה"פורמלית" להגדיר slice הוא בעזרת פקודת make (המייצרת עוד כמה מבנים בשפת גו). הפרמטרים שאנו שולחים הם:
1. טיפוס - כדי ליצור slice עלינו לציין "מערך" של טיפוס, במקרה שלנו int[].
2. length - אורך ה Slice שאנו רוצים לייצר.
3. Capacity - אורך המערך שגו תייצר, מאחורי הקלעים, עבור ה slice. ה slice לא יכול לחיות ללא מערך מאחוריו, כמו ש ArrayList או Vector לא יכולים לחיות ללא מערך (למי שמכיר את המימוש).
2. אנו בודקים את תוצר היצירה שלנו
1. len היא פקודה בשפה שבודקת אורך של מבנה, במקרה הזה ה slince
2. cap (קיצור של capacity) היא פקודה בשפה שבודקת את אורך התכולה השל המבנה - במקרה שלנו: אורך המערך.
3. צורת הגדרה אחרת היא ה slice literal.
   תחביר ההגדרה דומה מאוד להגדרה של מערך, ההבדל הוא שבהגדרה של מערך עלינו לציין בסוגריים את מספר האיברים (או אפשר פשוט לכתוב שלוש נקודות ...)
4. במקרה זה גו ייצור מערך בדיוק באורך של ה slice (כלומר: 5 איברים).
5. כעת אנו מבצעים פעולת slice על ה slice שלנו. נזכיר שהאינדקס לפני ה סימן : בפעולה - הוא איבר שייכלל ב slice שייווצר, והאינדקס שלאחר סימן ה : - לא ייכלל ב slice שייווצר.
6. התוצאה יכולה לרגע מעט להפתיע - אך היא הגיונית: הנה תרשים שיסביר אותה:

האורך של sliceOfSlice הוא אכן 3. ה capacity שלו הוא 4 מכיוון שיש לו עוד תא אחד לגדול במערך.

הוספת איברים ל slice

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

1. אנו יוצרים מערך של int בגודל 4, ומאתחלים אותו בערכים (השמה מרובה). יכולתי להשתמש בתחביר של array literal, אך מכיוון שהוא דומה כ"כ ל slice literal בחרתי בצורה המגושמת, אך המפורשת יותר.
2. מתוך המערך, אנו מבצעים פעולת גזירה - שיוצרת את slice. להזכיר: האינדקס הראשון כלול, והאינדקס השני לא. תחביר מקוצר לפעולה היה יכול להיות [2:]
3. כפי שאנו רואים slice הוא בגודל 2, וה capacity שלו הוא 4 - בגלל המערך שעליו הוא מבוסס.
4. אם אנו מציבים ערך במערך - הוא משתקף מיד ב slice. המערך הוא האחסון של ה slice.
5. כאשר אנו מוסיפים איבר ל slice, היכן הוא יאוחסן? - במערך, כל עוד הוא גדול מספיק.
   המשמעות היא שאנו דורסים את הערך הישן (100) בערך שנוסף ל slice. בעבודה עם מספר slices מעל אותו מערך - יש סכנה של דריסת ערכים הדדית.
6. הנה אני מדפיס את מצב המערך. v% הוא הסימן להציג את הטיפוס בפורמט ברירת-המחדל שלו. זו תצוגה טובה לצורך debugging.
7. ה slice כרגע בגודל 3 ו capacity של 4. מה יקרה אם נוסיף ל slice שני איברים, מערך ל capacity הנתון?
   הפעולה מצליחה, ואנו רואים שה capacity קפץ ל 8 (כמו Vector ב ++C, ג'אווה, וכו' - מגדילים את שטח האחסון פי 2).
8. כפי שאנו רואים ה slice גדל, אך לא המערך. מערך איננו יכול לגדול - בהגדרה.
   פקודת append הגדירה מערך חדש גדול פי 2, והעתיקה אליו את כל הערכים הקיימים. הקשר בין slice ל array ניתק - ו slice עכשיו מצביע (ומאחסן נתונים) במערך חדש שהוקצה עבורו.
9. הנה וידוא נוסף, שזה אכן מה שהתרחש: אנו מציבים ערך ב array - ורואים שהוא לא השפיע על הערך ב slice.

כפי שאתם רואים, ה slice מכסה לנו את ההתנהגות הכל-כך נדרשת של ArrayList.

Slice הוא בבירור האלמנט השימושי יותר בשפה, איתו תעבדו רוב הזמן - ולא עם מערכים. חשוב אבל להבין כיצד slices עובדים.

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

איך מסירים איבר מ slice? הרי המערך הוא קבוע ורציף בזיכרון... הנה דוגמה:

1. הדרך להסיר איברים היא בעצם ליצור slice חדש, שיכיל פחות איברים.
   התחביר של ... הוא expansion שהופך את ה slice לרשימה של פרמטרים - הצורה לה הפונקציה append מצפה.
2. אנו יכולים לראות שהפעולה הצליחה והמספר 10 נמחק מהרשימה.
   מדוע, אם כן, ל slice יש capacity של 4?
3. בגלל שפקודת append לא יצרה מערך חדש. היא בכלל לא מודעת לזה שביצענו מחיקה.
   כמו שראינו את הדוגמה הקודמת - הוספה של איבר ל slice מוסיף את הערך במקום הבא במערך - אם יש מקום לכך.

Structs

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

אפשר לחשוב על Struct כאובייקט ללא מתודות - רק members.

1. אנו מגדירים struct חדש בעזרת המילים השמורות type ו struct. בניגוד לג'אווה או #C בהם מקובל ששם של טיפוס (מחלקה, struct ב #C) מתחיל באות גדולה, בשפת גו האות הגדולה מציינת האם הטיפוס הוא פרטי לחבילה (אות קטנה) או ציבורי (אות גדולה)
1. בתוך ה struct אנו מגדירים את השדות (נקראים fields).
2. יש לנו 3 דרכים ליצור instance חדש של ה struct שהגדרנו
1. ע״י שימוש ב var - ה struct יאותחל לערכי 0.
   שפת גו לא מגדירה אם בצורה זו האובייקט ייווצר על ה stack או על ה heap - זה פרט מימוש של הקומפיילר. בד״כ הקומפיילר יבצע תהליך שנקרא escape analysis ויראה אם יש חובה להגדיר את המופע, במקרה הספציפי, על ה heap. העדפת ברירת המחדל היא להגדיר אובייקטים על ה stack (מכיוון ששחרור הזיכרון הוא אפקטיבי יותר).
2. ע״י שימוש במילה השמורה new, שיגרום ל:
1. האובייקט ייווצר על ה heap. כל הערכים יאותחלו לערכי אפס.
2. המשתנה sprite2 יכיל פויינטר לאובייקט, ולא את האובייקט עצמו.
3. ע״י צורת ה shorthand של יצירה והשמת ערכים. בצורה זו אנו מציבים ערכים בעצמנו. כמו צורה #1 - אין הבטחה אם האובייקט ייווצר על ה stack או ה heap.

כמה מלים על קונבנציית השמות בשפה:

• שם חבילה (package) משמש כ namespace דרכו ניגשים לאלמנטים בחבילה. על כן חשוב שזה יהיה שם קצר וברור. מקובל ששם לחבילה היא מילה בודדת באותיות קטנות, למשל "strings".
• כנ"ל לגבי שמות התיקיות המכילות את החבילה.
• הנה פרויקט של ה NYTimes שהחליטו לשבור את הכלל הזה - פשוט כי קשה להם לקרוא את השם כ nytimes. הם לא רגילים. כל כלל ניתן לשבירה, אם מוכנים לשלם את המחיר (כרגע זה מציף כמה מקרי קצה ב tooling של go).
• שלפנים (Getters/Setters) - אלו לא כ"כ מקובלים בשפה, אך אם אתם משתמשים בהם - עליהם להיות כשם ה filed עם אות ראשונה גדולה. 
• השדה: user (אות ראשונה קטנה = פרטי לחבילה)
• השלפן: User (אות ראשונה גדולה = ציבורי)
• כל הטיפוסים / משתנים האחרים הם ב MixedCaps, שזו צורה כמו CamelCase, עם ההחרגה שהאות הראשונה מציינת את הנראות.
• טיפוס/משתנה פרטי בחבילה: myUniqueType
• טיפוס/משתנה ציבורי: MyUniqueType
• ממשקים (interfaces) עם מתודה יחידה יקראו כמו שם המתודה, עם er של "התמחות":
• ממשק Reader המכיל את המתודה Read.
• ממשק Shopper המכיל את המתודה Shop.
• לא הוגדר, אך אני הייתי קורא לממשק עם מתודה יחידה ReadString בשם StringReader.
• אפשר למצוא עוד פירוט על ההגדרות הללו ב Effective Go.

Gopher עם סטייל - מקור

עניין של סגנון

אז איך סגנון הכתיבה "הנכון" או "המקובל" בשפת Go?

כיצד מתכנני השפה התכוונו שנכתוב תכניות, או אולי אפשר לשאול: כיצד המתכנתים הממש טובים כותבים קוד?

ראשית, ניתן לשים לב שסגנון הקוד ב Go הוא דיי דומה בין תכנית לתכנית. יש לכך כמה סיבות מרכזיות:

• הקומפיילר ו gofmt (שאני מקווה שרוב ה IDEs עובדים איתה) - מכתיבים חלק גדול מהסגנון. רוצים סוגריים מסולסלים בשורה חדשה? - אין.
• שפת Go היא מינימליסטית: אין Generics, ואין Meta-programming - כלים שלרוב הם הבסיס ליצירת סגנונות בשפה (ע"י Frameworks, בד"כ). אין הורשה, אין מחלקות מקוננות, אין מחלקות אבסטרקטיות. בעצם: אין מחלקות. כל אלו, כלים שעוזרים להגדיר "DSL" על גבי השפה - ואין אותם ב Go.
• הספריות הסטנדרטיות של שפת גו מכסות מרחב גדול של נושאים, שלרוב מגיעים כספריות צד-שלישי: בדיקות (יחידה/אינטגרציה/APIs, ועוד), Templating, עבודה עם HTTP, שרת ווב, טיפול ב JSON/XML, ועוד.
  ספריות, ובעצם ה APIs שלהם - נוטים להכתיב חלק גדול מהסגנון הכתיבה שלנו. אם כולם משתמשים באותן ספריות - הקוד הוא יפה.

ניתן לראות תכונה זו של השפה כ"אובדן אינדוודואליזם", או מצד שני - כ"היופי שבפרגמטיות". כתיבת קוד שיהיה עקבי במערכת גדולה (גוגל) - היה אחת ממטרות השפה. אני באופן אישי, אוהב את ה trade-off שנלקח - ומעדיף שפה מגבילה, אך שמכתיבה סגנון אחיד.


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

1. נהוג להשתמש בתחביר של if עם השמה מרובה, ובדיקת שגיאה  -באותה השורה. לרוב עבור טיפול בשגיאות.
2. מה שלא נהוג לעשות הוא להיכנס לקינון של if או בלוקים מסוג אחר. יש הרבה מפתחי ג'אווה שכותבים כך קוד - אז זה מצב לא רצוי ב Go.
3. מה שיש לחתור אליו הוא להישאר, עד כמה שאפשר, ברמת אינדנטציה מינימלית. זה אומר:
1. לפצל פונקציות לפונקציות קטנות יותר.
2. במקרה לעיל (#2) הסיבה לכתוב קוד בתוך ה else היה ה scope בו הוגדר המשתנה err. אין בעיה: ניתן להגדיר אותו ב scope רחב יותר - ואז להיפטר מהאינדנטציה הנוספת.
3. עוד דבר שמצמצם את כמות שורות הקוד באינדנטציה במשפטי if הוא, לטפל קודם במקרה הפשוט (במקרה שלנו: return x - שורה אחת באינדנטציה), ואז במקרה המורכב יותר - מחוץ ל if (במקרה שלנו: הטיפול בשגיאה - 4 שורות שעכשיו אינן באינדנטציה).

הרעיון הזה הוא לא מקורי. הוא אפילו לא חדש: ניתן למצוא אותו בספר Code Complete (עליו כתבתי פוסט) שנכתב אי שם בשנות ה-90 המוקדמות. פשוט הקהילה של גו (כנראה בעקבות צורת הקוד בה כתובות הספריות של גו) - החליטה לאמץ אותו.

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

לא מופרך להאמין שבגו תשתמשו ביחידות זמן שונות (שניות, מילי-שניות, ננו-שניות). במקום ליצור (קבוע?) עם ערך מספרי ושם או הערה שלא תסביר אותו היטב, יש בשפה טיפוס בשם time.Duration שהופך את ההגדרה להרבה יותר אלגנטית:

עוד כמה נקודות קצרות:

• מתכנתי Go אוהבים לכתוב בדיקות-יחידה, והרבה!
• עושים הבחנה ברורה בין בדיקות יחידה (שם הפונקציה מתחיל ב Test), בדיקות ביצועים (שם הפונקציה מתחיל ב Benchmark) ובדיקות קבלה / לצורך תיעוד (שם הפונקציה מתחיל ב Example).
• עדיף להשתמש ב switch ולא ב if else if.
• אני במקור דווקא מחבב את if else if, אבל ב Go אין צורך ב break - אנסה באמת לזרום עם מה שמקובל.
• עדיף להחזיר כמה ערכים מפונקציה, ולא להשתמש בפרמטר שהוא pointer כ "out value" (כמו שמקובל ב #C).

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

סיכום קצר

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


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



----


לינקים רלוונטיים


Slice Tricks in Go - לא ממש טריקים, אלא ריכוז הפעולות השונות על slices.

Best practices for a new Go developer - המלצות משורה של מתכנתים מנוסים ב Go, על מה כדאי לשים לב כשנכנסים לשפה. דוגמאות:

• אנשים חדשים נוטים לעשות overuse למודל ה concurrency של Go (כי הוא "כ'כ מגניב"?!).
• נסו להתמקד ולהבין את מודל ה interfaces לעומק - זה לב השפה (רלוונטי למי שלא הגיע מג'אווה או #C).
• השתמשו ב gofmt, כהרגל - כבר מההתחלה.

twelve Go best practices - גם נחמד

50 גוונים של Go - טעויות נפוצות של מתכנתים מתחילים בגו. מקום טוב ללמוד ממנו "פינות" של השפה.

Code Review Comments - מדריך לכתיבת הערות בגו

ברומא, התנהג כרומאי, Organizing Go Code, שפת גו - ל Gophers  - מצגות טובות על סגנון כתיבה מקובל בגו.