להבין Dependency Injection [מעודכן]

עדכון: ספטמבר 2014 - הפוסט חודש כליל. הפוסט המקורי פורסם בספטמבר 2012.

לשימוש ב Dependency Injection (בקיצור: DI) יש שני מניעים עיקריים:

• הקפדה על ה Single Responsibility Principle[א] (בקיצור: SRP).
• ביצוע בדיקות יחידה / בדיקות אינטגרציה.

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

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

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


בפוסט זה אני מנסה גישה חדשה: פרסמתי את דוגמאות הקוד (העובדות) מהפוסט בגיטהאב: https://github.com/baronlior/di-post
בואו נראה איך זה עובד...

DI בהיבט של SRP


בואו נתבונן על הקוד הבא:

הממשק

ספק השירות

צרכן השירות

הנה השקענו, בהגדרת Interface (ע"פ עקרון ה Program to an interface), בהפרדה בין נותן שירות לצרכן השירות. הפרדה זו ניתן לקטלג כ"ניהול תלויות" / "Low Coupling" - ערכים בסיסיים בהנדסת תוכנה.

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

אמנם המשתנה המקומי artist הוא מסוג הממשק Artist - אך השימוש ב new מחייב שיהיה import ותלות למחלקה הקונקרטית. זרעי הפרת-התלויות - נזרעו.

מדוע הפסימיות? המתכנת ישתמש בממשק מבלי קשר ל imports הזמינים...

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

באופן דומה חשבו על המתכנת: הממשק הוא כמו גדר - זהו מחסום פיסי לא מאתגר. מה הבעיה ללכת לקוד של ה Interface ולשנות אותו? או לשנות את ההגדרה בקוד של המשתנה מטיפוס Artist (הממשק) לטיפוס Michelangelo (המחלקה הקונקרטית)? ממש כלום.

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

מלבד החשש לטשטוש הגבולות שהוגדרו, יש פה עניין של "קוד מיותר".
יצירת הקשרים בין המלקות הוא לא חלק מה "Single Responsibility" של המחלקה - ופשוט עדיף שלא יהיה שם. עדיף ליצור מחלקה מיוחדת (למשל: Factory) שזהו ייעודה בחיים.

איך אפשר לעשות זאת?
- פשוט "נעיף" את ה import של המחלקה הקונקרטית מצרכן השירות ונוסיף מחלקה שהכרת המחלקות הקונקרטיות הוא ייעודה. Repository בו מחלקות יכולות להירשם, ולמצוא אחת את השנייה ע"פ "סימנים" מסוימים (שם, שם התפקיד, ממשק, וכו'). נקרא לו Service Locator:

דוגמא לשימוש ב Service Locator

הנה, כרגע אין לנו תלויות במימוש הקונקרטי - סגרנו את "הפרצה בגדר"!

עם השנים התפתחו ספריות של Service Locator שמקלות על המפתח, ועם הזמן החליטו להחליף את סדר האחריויות: במקום שמחלקה תגדיר למה היא זקוקה ("the artist"), מחלקת ה Service Locator תתפוס פיקוד והיא "תזריק" לצרכן השירות את מה שהוא צריך. מימושים אלו נקראו בהתחלה "Inverse of Control" (בקיצור: IoC), עד שמרטין פאוולר טבע את המונח "Dependency Injection" (בקיצור: DI) אותו אנו מכירים היום.


הנה דוגמה לשימוש ב JSR-330 (הסטנדרט של ג'אווה ל DI):

ה Annotation של Inject@ מסמנת שלבנאי של Michelangelo "יוזרק" המימוש הקונקרטי של המחלקה מסוג ה Painter לה הוא זקוק - מה שמותיר את הקוד של Michelangelo נקי למדי מכל עניין של ניהול הקשרים בין המחלקות.

היכן מוגדר הקשר בין המחלקות? במחלקה אחרת, ייעודית לעניין:

מחלקה זו אינה מוגבלת בתלויות שלה - התפקיד שלה הוא "לשאת בנטל" התלויות של האפליקציה.

הקישור בין Inject@ והפונקציה ()bind נעשית בספריית ה DI בשם Google Guice - ה Reference Implementation הרשמי של JSR-330.

אי אפשר לא להזכיר את Spring - הספרייה שבעצם הפכה את DI לכ"כ נפוץ, והופיעה זמן מה לפני JSR-330 או Guice. ספרינג היא עדיין כנראה ספריית ה DI הנפוצה ביותר בעולם הג'אווה.

ההיסטוריה של ה DI/IoC. מקור

הערה: בעוד המינוח "Dependency Injection" היה ברור יותר מ "IoC" המעורפל-משהו, בד בדד הוא כנראה הותיר גם לאנשים מספיק מרחב לדמיין מהי "הזרקה". הזרקה, למשל, יכולה להיות גם השמה ב Reflection של Private member של מחלקה, לא? למשל כך:

זהו תחביר מקוצר לדוגמה האחרונה. במקום לקבל את הערך כפרמטר לבנאי המחלקה, ושם להציב אותו כ private member - אנו פשוט מציינים את ה Inject@ ישירות על ה private member של המחלקה.

מצד אחד חסכנו שורת קוד משעממת, מצד שני "עקפנו" את ה encapsulation של ג'אווה והתרנו לגשת ל private member של המחלקה.

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

1. טשטוש הגבולות של מושג ה private בג'אווה.
2. בעוד בנאי עם הרבה (נאמר 10) פרמטרים יציק לנו, וידרבן אותנו לנהל תלויות בצורה קפדנית / לחלק את המחלקה לכמה מחלקות קטנות יותר ועם התמחות מוגדרת יותר - (מניסיון) לא כ"כ מפריע לנו שיש מחלקה עם 10 פרמטרים עליהם יש Inject@.
3. שימוש מוגבר ב class members ולא משתנים עם scope מצומצם יותר - כי כ"כ קל להגדיר בדרך זו משתנים.

סה"כ "הזרקה" של משתנים לבנאי המחלקה נחשבת הדרך המועדפת לניהול תלויות.
הנחת היסוד הוא ששימוש ב DI בא להבטיח ניהול תלויות מדויק וקפדני, ולא רק "לקצר את כתיבת הקוד". הדרך הכי קצרה לנהל תלויות היא כנראה שימוש ב new, בכל מקום שרק רוצים.
ולכן, השמה ל private member נראית קצת מוזרה: כמו אכילת קינואה וברוקולי עם צ'יפס מטוגן בצד. מותר, אבל מוזר.

ריבוי צורות (Polymorphism)

אם שמתם לב, הדרך להגדיר קשר בין הממשק למחלקה הקונקרטית (פקודת ()bind) היא על בסיס הטיפוס (class) בג'אווה. בתחילת הדרך נהוג היה דווקא לרשום מחלקה תחת שם (מחרוזת מסוימת) ואז לבקש אותה בחזרה ב Service Lookup / בהזרקה. עם הזמן הגיעו ל 2 תובנות:

• שם המחלקה הוא כנראה התיאור הברור והצפוי ביותר שלה.
• השימוש ב class object בשילוב עם Generics מאפשר ליצור ספריית DI / Service Lookup ללא הצורך המרגיז בביצוע downcasting.

מה קורה כאשר רוצים להשתמש בריבוי צורות?

ברור לכם שברגע שהמיפוי הוא לא חד-חד ערכי, ה framework לא יצליח לבצע resolving נכון ב runtime. יש frameworks שמתירים מצבים שהם לא חד-חד ערכיים, בהנחה שהם יצליחו לנחש נכון, ויש כאלו שפשוט זורקים שגיאה בזמן ריצה, למשל: "binding xxx was already configured".

מה עושים? יש לכך כמה פתרונות (ל Spring Framework, למשל, יש כמה דרכים משלה), אך הפתרון המקובל ב JSR-330 הוא להוסיף Qualifiers (מעין תגיות) על ה binding ועל הבקשה (ועל צרכן השירות - בהתאמה), וכך לבצע את ההתאמה: התאמה ע"פ תיאור הכוונה.

רישום של 2 מימושים לממשק Painter, תחת שמות שונים

הנה המימוש המחלקה Michelangelo שמקבלת שני מימושים שונים של Painter:

הדוגמה היא רק בכדי להמחיש את נושא ה DI

DI בהיבט של בדיקות יחידה/אינטגרציה

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

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

ראינו את גישת ה Qualifiers של DI, שהתאימה לנו עבור מקרים של Polymorphism אך לא תתאים למקרים של בדיקות. צרכן השירות לא יכול לבקש משהו אחד בזמן הרצה רגילה, ומשהו אחר בזמן בדיקות. הוא לא אמור להיות מודע לסוג ההרצה שהוא עובד (אבוי אם כן...).

מה שעושים הוא פשוט להוסיף קונפיגורציות שונות לבדיקות, באופן הבא:

אזור ירוק - הכנסת הסביבה הבדיקה; אזור הכתום - הרצת הבדיקה.

1. אנו בודקים את מחלקת ה Artist ולכן צריכים מופע שלה. כדי שה DI Framework יוכל לעבוד, אנו צריכים ליצור את Michelangelo בעצמו בעזרת ה Framework.
   יש פה הזרקה ל member. מה שאני לא מרשה לעצמי לעשות בקוד production, אני מרשה לעצמי לעשות בקוד של בדיקות - כדי לכתוב קוד קצר יותר.
2. אני יוצר mock ל Painter. לא רציתי להתעסק עם ספריית mocking (כמו Mockito או PowerMock) ולכן יצרתי mock כ Anonymous Class.
3. פונקציה זו היא בעצם inline של הקונפיגורציה. בעוד שבקוד production אנו רוצים להפריד את ה wiring מהקוד, דווקא בבדיקה ה wiring הוא חשוב להבנת הבדיקה, ולכן אני מעדיף שיהיה באותו הקובץ. שוב השתמשתי ב Anonymous Class.
4. זו הבדיקה עצמה, הפעלה של המתודה ()createArt מול התוצאה הצפויה (הבדיקה עוברת).

סיכום

בפוסט זה סקרנו את נושא ה Dependency Injection ושורשיו, וניסינו להפוך "שימוש אוטומטי" בכלי DI, לשימוש מושכל יותר.

מה השתנה בשנתיים האחרונות שגרם לי לחדש את הפוסט?
אני חושב שבאופן אישי יצא לי להיחשף בעבר ל DI בעיקר ככלי לביצוע בדיקות יחידה - את ניהול התלויות העיקרי עשינו במערכת (הישנה) על גבי JNDI של JEE (סוג של Service Locator). את תמונת עולם זו שיקפתי בפוסט בצורה דיי נחרצת - כפי שהגיב והעיר ויטלי.

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

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

• אין צורך ב Framework בכדי לבצע DI. בסה"כ, DI הוא רעיון, וה Frameworks השונים רק יוצרים אוטומציה של התהליך.
• באוטומציה (או Framework) יש יתרון שהוא גם בעיה: היא חוסכת מאיתנו את הצורך בהבנה עמוקה. ללא הבנה עמוקה ניתן לשכוח מדוע אנו עושים מה שאנו עושים (במקרה שלנו - DI) - ולפתע למצוא את עצמנו עושים משהו אחר מהכוונה המקורית.
  אני נוטה בשנים האחרונות להטמיע רעיונות ראשית ללא Framework, בכדי להבין לעומק את הנושא - ורק בסיבוב השני להוסיף את ה Framework שמקל על העבודה. זה כמו ללמוד "חשבון" (מתמטיקה בסיסית) עם מחשבון ביד מהרגע הראשון: האם לא עדיף ללמוד כמה חודשים ללא מחשבון - ורק אז להוסיף אותו?
• DI הוא לרוב רק חלק קטן במערך המודולריזציה של המערכת. שימוש ב DI לא מבטיח איכות או מודולריות, בפני עצמו. הוא רק כלי (נוסף) להשיג מטרות אלו.
• אני לא שולל את הרעיון של אי-שימוש ב DI. למשל: להפסיק ליצור interface לכל מחלקה (מלבד מקרים של ריבוי צורות), להסתמך על public vs. private להגדרת הממשק, ולצמצם את השימוש ב DI למינימום האפשרי (למשל: עבור בדיקות אינטגרציה, או ניהול תלויות ברמת השירותים בלבד). בסופו של דבר אנו משלמים לא מעט עבור ההגנה שמספקת גישת ה Program to Interface (בצורה הדקדקנית שלה) וצוותים מסוימים / פרוייקטים מסוימים - יכולים להסתדר מספיק טוב עם פחות הגנות, ועדיף לתת להם להתקדם מהר יותר. 

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

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

----

[א] עקרון זה מוכר גם כ Separation of Concerns או Segregation of Duties. הכוונה היא שכל יחידת קוד (פונקציה, מחלקה, מודול) יעשו דבר אחד, ודבר אחד בלבד. צד שני של אותו המטבע הוא שכל אחריות תהיה בידיים של יחידת קוד אחת גם כן. כלל זה עוזר ליצור סדר במערכת, ולוודא שמי שכותב את הקוד יראה לנגד עיניו את התמונה המלאה ולא חלקים ממנה (כי כל האחריות נמצאת באותו המקום).


קישורים:

DI קליל ברובי
הפסיכולוגיה של בדיקות תוכנה - מישקו הארווי (היוצר של AngularJS ו jsTestDriver).

שפת Ruby: מה זה השטויות האלה?!

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

---

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

רובי דומה בהיבטים רבים לשפת Python, מכיוון שהיא:

• שפת high level, כמעט scripting language
• שפת general purpose
• שפת Dynamic typing
• התחביר שלה דומה

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

%w(abc def ghi)

(ללא מרכאות) הוא קיצור מקובל ל

["abc", "def", "ghi"]

דוגמה נוספת היא הבחירה במונחים:

• string.downcase במקום string.lowercase 
• string.gsub במקום string.replace (יש מתודה בשם replace, אך היא עושה משהו אחר)
• to_s במקום toString, כאשר יש גם מתודה בשם to_str - אבל לא נכון להשתמש בה, אם המחלקה היא לא סוג של string בפני עצמו.

דבר אחרון שעשוי להיות דיי מוזר הוא השימוש הרב בסימני פיסוק: סימני "?" או "!" משמשים כקונבנציה על שמות של מתודות/פונקציות. יש שימוש ב <=, גם ב @, או $ בשמות של משתנים, ויש גם שימוש ב :, |, &, וסימנים אחרים.

אני רואה מדריכים של רובי שמצהירים בגאווה: "הצלחנו ליצור קוד שהוא ממש כמו פסקה בשפה האנגלית!".

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

"@הצלחנו: ליצור (!), קוד :שהוא |ממש| כמו => פסקה? בשפה! האנגלית!" - כן, בטח!

---

רובי, בניגוד ל Python, היא שפת OO "אמיתית" עם classes כפי שאנו מכירים אותם בג'אווה / #C.

רובי הושפעה גם מ SmallTalk, משפת LISP ומ Perl. כן,... Perl השפה שעליה נאמר שהיא שפה לכתיבה-בלבד.

לזכותה של רובי יאמר שהיא אחת השפות שצמחו במהירות הגדולות ביותר, ויש לה קהילה גדולה, איכותית, ופעילה. חוזק גדול מאוד של הקהילה הוא תשתית ה FullStack Web Development בשם Ruby on Rails (בקיצור: RoR), אבל יש לה גם כח ונוכחות מעבר לכך. ניתן לציין את RSpec, Chef, Puppet, Vagrant, Cucumber - שהשפעתם על תעשיית התוכנה היא רבה.

מתכנת ששולט ב Ruby יכול לכתוב בה בקצב מהיר מאוד, יותר מאשר ב Python - כך טוענים.

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

פוסט זה שייך לסדרה: רובי (Ruby) למפתחי ג'אווה ותיקים

התקנה

התקנת רובי פשוטה הרבה יותר על לינוקס.

משתמשי חלונות: כדאי להשתמש בלינק הזה, ולהשתמש בגרסת 32 bit, כי גרסת ה 64 היא בעייתית.

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

אם אתם רוצים לפתח (דאא!) אז תזדקקו דיי מהר גם ל Devkit. קובץ ההתקנה הוא בסך הכל ZIP שנפתח לאיזו תיקיה. בתיקיה זו (אני עובד בחלונות) הקלידו ב command line:

> ruby dk.rb init

> ruby dk.rb install

ה IDE החביב עלי הוא (כמובן) RubyMine.

התקנת רובי תוסיף לכם אפליקציה בשם irb (שהוא ה Interactive Ruby Shell, להפעלה מה commandline / shell) שבו תוכלו לבדוק במחזור feedback של שניות פקודות שלא ברור לכם בדיוק כיצד הן מתנהגות. אפשר להתקין את wirble שמאפשר autocomplete ו syntax highlighting ב irb.

כחלק מהתקנת רובי מגיעה גם אפליקציה בשם gem, שהוא ה Package manager של רובי (ממש כמו אלו של לינוקס, ממנה הושפעו הכלים של רובי לא-מעט). בעזרת gem מתקינים חבילות רובי. החבילה הראשונה שאני ממליץ עליה היא rspec ספריית בדיקות היחידה / BDD (שבדמותה נוצרה Jasmine של ג'אווהסקריפט - למי שמכיר). פשוט הקלידו בשורת הפקודה:

> gem install rspec

בואו נצא ידי חובה וניצור hello world קטן:

ברובי יש 2 מתודות להדפסה:
print שהיא המקבילה ל System.out.print בג'אווה.
ו puts (קיצור של put string. כמה טוב שלא בחרו לקרוא לה disuninject_string) שהיא המקבילה של System.out.println בג'אווה, ובה נשתמש בד"כ.

שתי הדוגמאות למעלה תקינות לחלוטין בשפת רובי, אולם הדוגמה השנייה נחשבת לעדיפה.
מדוע?

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

טבילת אש ראשונה

1. שמות מחלקות חייבים להתחיל באות גדולה.
   כאשר אנו משתמשים באות גדולה בתחילת שם משתנה - הוא הופך לקבוע. אפשר לומר שגם מחלקה היא סוג של קבוע, כי הרי המחלקה (לא המופעים שלה) - לא משתנה מרגע שהוגדרה.
   המחלקה שלנו יורשת מהמחלקה LivingCreature.
2. ה Constructor הוא מתודה (מתודות מוגרות ע"י def, קיצור של define) בשם initialize. אין צורך להגדיר טיפוסים (int, string וכו') של משתנים ברובי - זו שפה דינמית.
3. משתני מופע (נקראים instance variables, מה שנקרא בג'אווה "members") מוגדרים ע"י סימן @ בתחילת השם. שימו לב שאת משתני המחלקה מגדירים רק בתוך מתודות, ולא בתוך המחלקה - כפי שמקובל בג'אווה. עצם השימוש במשתנה עם שם שמתחיל ב@ - מגדיר אותו כ member של המחלקה.
4. משתני מחלקה (המקבילים ל static members בג'אווה) מוגדרים ע"י 2 סימני @.
   שימוש במשתני מחלקה נחשב כפרקטיקה לא מומלצת ברובי, בדומה לג'אווה.
5. שמות מתודות, משתנים וקבצים ברובי נעשים ע"י שימוש ב snake_case (בהקבלה ל camelCase שבשימוש בג'אווה).
   מקובל מאוד שמתודה או פונקציה ללא פרמטרים - לעולם לא תופיע עם סוגריים.
   משתמשים ב PascalCase (אות גדולה ראשונה) להגדרות שמות מחלקות ומודולים.
   עבור קבועים, מקובל מאוד להשתמש ב SCREAMING_SNAKE_CASE (בדומה לג'אווה).
6. אוקיי... הנה קוד קצת מוזר. זהו התחביר (המוזר) ברובי למשפט if מקוצר. משפטי if רגילים דורשים שימוש ב end.
   התחביר של המשפט הוא: <עשה X> אם <תנאי>, במקרה שלנו: "עשה את הפרש הגילאים" אם "הגיל קטן מה lifespan הממוצע".
   אבל ביצוע חישוב וזריקה של התשובה לאוויר - היא "עשייה"?
   כן. מכיוון שהשורה האחרונה במתודה / פונקציה ברובי - היא ערך ההחזרה (אפשר להשתמש ב return כדי להחזיר ערך מאמצע הפונקציה).
   אין פונקציות מסוג void ברובי - תמיד פונקציה תחזיר ערך. אם לא הגדרנו אותו / אין ערך בשורה האחרונה - אזי יחזור nil.
7. נעבור להרצה:
   אנו יוצרים מופע חדש של המחלקה: ה new נמצא בצד ההפוך לזה שאנו רגילים בגא'ווה, והוא מקבל את הארגומנטים עבור ה constructor.
   הפעלה של מתודות - מקובל מאוד לשרשר ברובי, והרבה פונקציות בספריות הסטנדרטיות של רובי מחזירות reference לעצמן לצורך כך.
   כפי שכבר ציינו, אין צורך בסוגריים בהפעלת time_to_live, כי היא לא מקבלת ארגומנטים.

הערך שנותר לבחור בן 21 לחיות (ע"פ התוכנה) - הוא שישים שנה.
כאשר שואלים את התוכנה על בחור בן 90, היא לא מבצעת כלום (כי התנאי במשפט ה if לא מתקיים) - ולכן חוזר nil.
כשנשלח nil ל puts - הוא מדפיס שורה ריקה.

שונות

רובי מספקת דרך מובנה לבצע formatting בסיסי של מחרוזות. ע"י שימוש ב {}# (בתוך מחרוזת עם גרשיים), רובי תשתול במחרוזת ערכים שזמינים ב scope. אהבתי!

בדומה לפייטון, ניתן לבצע ברובי השמה מרובה (a,b = c,d).

שפות high level כמו רובי מעודדות את המתכנתים להשתמש בחופשיות במחרוזות בכדי לתאר "מצבים חוזרים". בשפת C היינו משתמשים בצורך זה ב const int, בג'אווה היינו משתמשים ב enum. ל JVM יש גם מנגנון של String Pooling שמאפשר לייצר אותה מחרוזת כמה פעמים - אך לנהל רק עותק אחד בזיכרון. אני מניח שיכולת זו מבוססת על תהליך הקומפילציה של ג'אווה.

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

הערה: symbols הם לא ממש מחרוזות, ולא ניתן להפעיל עליהם מתודות של מחרוזות, אולם נשמר הקשר ש:

:hello.object_id == hello.object_id 

בעוד

"hello".object_id != "hello".object_id 

בדוגמה למעלה a ו b הן מחרוזות, בעוד c ו d הם symbols
בשורת ה puts השתמשתי בכפל עם מחרוזת, שזהו קיצור לפקודת join על מערך. כך אני גורם ל puts להדפיס שורה אחת עם פסיקים - ממש כמו שמופיע בהערה באותה השורה.

עוד דבר קטן שאנו רואים בדוגמה הוא את קונבנציית השמות למתודות של "!": בעוד המתודה chop מחזירה עותק של המחרוזת a שהוסר ממנה הסימן האחרון (אנו לא עושים כלום עם הערך שחזר בדוגמה), המתודה !chop מסירה מהמחרוזת b את הערך האחרון ומחזירה nil.

לא ניתן להשתמש ב"!" בכל מתודה שרוצים: מי שכתב את המחלקה string יצר שתי מתודות: chop ו !chop.

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

לולאות ברובי דומות מאוד לפייטון או ג'אווהסקריפט: פורמט for ... in.
בדומה לג'אווהסקריפט (שם לולאה עוברת גם על פרמטרים של אובייקט האב), יש בלולאת for רגילה - התנהגות שלרוב איננה רצויה: הערך שהוגדר (item במקרה שלנו) - ממשיך לחיות מעבר ל scope של המערך.

לפעמים זה שימושי, פעמים רבות אחרות זה מבלבל - ולכן כדאי לעבוד עם התחביר השני (שדומה מאוד ל each של jQuery). התחביר השני שקול לחלוטין, מלבד כך שהערך שהוגדר (item2 בדוגמה) חי רק ב scope של הלולאה.

השימוש של התחביר השני רחב יותר מאשר סתם לולאות והוא נקרא block, הוא בעצם סוג של inline function שמעובר למתודה (each או select).

הנה דוגמה של שימוש במתודה select של מערך (סוג של filter: ערך ההחזרה הוא רק משתנים עבורם היה ערך חיובי). התחביר ~= הוא קיצור להתאמה של מחרוזת (color) ל regular expression (שאותה כותבים בין קווים נטויים, במקרה שלנו הופעת האות e).
כפי שאתם זוכרים, השורה האחרונה בפונקציה - היא ערך ההחזרה.

עוד מבנה נתונים "טבעי" בשפת רבי הוא ה Hash (המקבילה ל Map או HashTable בג'אווה).
התחביר הוא key => value. כשנתקלתי לראשונה בקטע קוד שכזה - לא שיערתי שמדובר בעצם ב Map: החץ נראה "חשוב מדי" מכדי לשמש כסימן הפרדה פשוט.

מאז גרסה 1.9 רובי הגדירה תחביר מקוצר חדש ל Hash שהמפתחות שלו הם symbols (שזה סוג של best practice). הרי הוא לפניכם.

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

כמה השלמות חשובות

self ברובי יכול להזכיר this בג'אווה, אבל ההתנהגות שלו שונה. אם הוגדר בתוך מתודה - הוא יצביע על המתודה, אם בתוך מחלקה ומחוץ למתודה - אזי על המחלקה, ואם מחוץ למחלקה - הוא יצביע על המרחב הגלובלי "main".

ברובי ניתן לארגן את המחלקות / קבועים / וכו' בתוך modules (דומה ל packages ב ++C או #C)
כדי לנווט בתוך ה module - אנו משתמשים בסימן ::

:: מאפשר גישה למה שנחשב "קבועים" ברובי: מודולים, מחלקות, ומשתנים קבועים (כולם מתחילים באות גדולה).


בלוקים הם "חתיכות של קוד" שאנו שולחים בפרמטר לפונקציה (שימושים נפוצים הם פונקציות כמו each, filter, וכו')
הנה התחביר של הבלוק:

מקור

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

סיכום

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

שפת רובי היא מורכבת ועשירה, והיכולת "לקרוא כל קוד ברובי" - דורשת כנראה למידה ארוכה בהרבה מפוסט זה (שלא לדבר על היכולת "לכתוב כל קוד ברובי"). לרובי יש ספריות ספציפיות שיש להכיר, טכניקות של metaprogramming - שנמצאות בשימוש לא מובטל, ועוד.

מפרשן (Interpreter) ברירת המחדל של רובי נקרא MRI (קיצור של Matz's Ruby Interpreter). הוא הסטנדרט, הוא עושה את העבודה - אבל נחשב אטי, אטי יותר מ Python - לדוגמה.

האם זה באמת נכון ומתי? קשה ממש לומר. יש הרבה מבחני ביצועים שמראים דברים שונים. לכל הפחות: זהו נושא בדיון.
עוד מגבלה של MRI היא שאין לו באמת multi-threading, ואין לו parallelism (קרי: שימוש ב GPU, SIMD, וכו'). אלטרנטיבה מקובלת לסביבה שכזו היא JRuby - המפרשן של רובי שרץ על JVM (מהיר יותר, multi-threaded וכו').

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


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



תודה לולדימיר טקצ (מומחה רובי) ששימוש כ Reviewer לדוגמאות הקוד, והציע כמה שיפורים.


----

קישורים:

Ruby tricks to make your code more fun and less readable - השלמה טובה לפוסט. חבל לי לשכתב את מה שנכתב כאן בצורה יפה.

מדריך Coding Style לרובי, שימושי ומלמד.

סשן ביוטיוב: Functional Development in Ruby