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

• מופעים מכילים state – משתנים
• מחלקות מכילות מתודות וקבועים
• מכיוון שמחלקה היא גם מופע – אזי היא גם מכילה משתנים, אם כי ב\”רמה\” אחרת.

class MyClass
  def self.my_class_method
    puts \'first!\'
  end

  def MyClass.second_class_method
    puts \'second!\'
  end

  class << self
    def MyClass.third_class_method
      puts \'third!\'
    end
  end
end

x = MyClass.new

MyClass.my_class_method # first!
MyClass.second_class_method # second!
MyClass.third_class_method # third!

x.my_class_method # error !@#$!
x.class.my_class_method # first!

הנה דוגמת קוד בה הגדרנו, בשלושה אופנים שונים, מתודות מחלקה.
הדרך השלישית נראית מעט מוזרה. מה שעשינו הוא קודם כל להחליף scope ל scope של ה singleton class של האובייקט MyClass (שהוא גם אובייקט לכל דבר) – ושם הגדרנו את המתודה. זאת מכיוון שמתודות מחלקה מוגדרות בעצם על ה singleton class של אובייקט המחלקה. מבלבל משהו.

מתוך המופע x אינני יכול לקרוא למתודות המחלקה של MyClass (למרות שאני מופע של MyClass), אלא רק בעזרת התייחסות (reference) למחלקה עצמה (למשל: x.class).

משתני מחלקה וקבועים
את משתני המחלקה אנו מכירים מהפוסט הראשון – הם מתחילים ב @@ והם דומים ל static fields בג\’אווה. ניתן לגשת אליהם מתוך מתודות של המופע.

נזכיר שגם משתני מופע (@) וגם משתני מחלקה (@@) הם private members. ניתן לגשת אליהם מתוך מתודות של המחלקה / מופע – אך לא מתוך קריאה ל x.@some_variable (מדוע? מכיוון שציינו את מקבל ההודעה, כמובן!)

class MyClass
  @@y = 4
  Z = @@y

  def foo
    puts @@y
    @@y += 1
  end
end

MyClass.new.foo  # first instance -> 4
MyClass.new.foo  # second instance -> 5
# MyClass.new.@@y = syntax error

x = MyClass.new
puts MyClass::Z # 4
puts x::Z # error!

אופיים של קבועים (Z – במקרה שלנו) נקבע ע\”י כך ששמם שמתחיל באות גדולה. שימו לב שמחלקות ומודולים – הם (אובייקטים) קבועים בשפת רובי.

מתודות ישירות / יחידניות (singleton method)
בשונה מג\’אווה ניתן להגדיר מתודות על מופע בודד – ולא על המחלקה.

class MyClass
  def foo
    puts \'yay!\'
  end
end

y = MyClass.new

def y.goo
  puts \'woo\'
end

x = MyClass.new

y.goo # woo
puts y.singleton_class.method_defined? :goo # true

puts x.singleton_class.method_defined? :goo # false
x.goo # NoMethodError

כלומר: המתודה goo קיימת רק על המופע y – ולא על שאר המופעים במחלקה.
אם אתם זוכרים את הכללים שלמעלה – מופע (אובייקט) מכיל רק state ולא מתודות. מתודות יושבות על מחלקות או מודולים. כיצד זה מסתדר עם מה הקוד שזה עתה ראינו?

ובכן… ברגע שאנו מגדירים מתודה על \”מופע\”, בעצם מאחורי הקלעים נוצרת מחלקה יחידנית (singleton class), חסרת שם, שתארח את המתודה הזו. המופע יחזיק התייחסות (reference) למחלקה היחידנית – יכולה להיות לו אחת כזו, לכל היותר.

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

המחלקה היחידנית של MyClass היא לא חלק מהיררכיית ההורשה של המופע x (היררכית הורשה היא עניין אישי ברובי) – ולכן אם מתודת המחלקה נקראת ישירות מתוך המופע (x.some_class_method) – המופע לא ימצא אותה.

הנה דרך נוספת להגדיר singleton method על המחלקה x

x = MyClass.new
y = MyClass.new

class << x
  def poo
    puts \'ok\'
  end
end

puts x.poo # ok
puts y.poo # NoMethodError

הביטוי class << x גורם לנו להכנס ל scope של מהחלקה היחידנית. פשוט.
בכדי שלא יהיה משמעם, קיים הבדל בין שתי דרכי ההגדרה של מתודה על מחלקה יחידנית – הבדל שקשור לנראות של קבועים על המחלקה היחידנית. בצורת ההגדרה הקודמת  הפונקציה לא \”תראה\” את הקבועים שעל המחלקה היחידנית, ואילו בצורת ההגדרה הנוכחית – הם יהיו זמינים מחלקה. למה? מדוע? – לא חפרתי מספיק בכדי להבין…

הערה אחרונה בנושא: הגדרת נראות private למתודת מחלקה (class method) נעשית בצורה מעט שונה: לא ע\”י שימוש ב private שאנו משתמשים עבור מתודות מופע, אלא ע\”י שימוש ב private_class_method. שימוש מקובל ב directive הזה הוא להחביא את המתודה new:: בכדי להגדיר דפוס עיצוב של Singleton (של GOF).
ה directives של הנראות (private, public, protected) הן בעצם פונקציות של המחלקה Module המשפיעות על המטא-מודל של האובייקטים ברובי. מכיוון שמתודות מחלקה לא נמצאות באמת על המחלקה (אלא על המחלקה היחידנית של המחלקה) – זקוקים למנגנון מעט שונה בכדי לשנות את הנראות שלהם מבלי לסבך. מבלי לסבך את המפשן של רובי, התכוונתי.

זוכרים שהזכרנו בתחילת הקטע את המטאפורה של המחלקה כ\”שק של תכונות\”?
בואו נראה התנהגות זו בפעולה:

class MyClass
  def foo
    puts \'aleph\'
  end

  def foo
    puts \'beth\'
  end
end

x = MyClass.new
x.foo # beth

הגדרנו מתודה בשם foo, ואז הגדרנו אותה שוב.
התוצאה? דריסה של רישום המתודה הראשון ברישום השנה – וזה מה שנשאר.

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

הנה דוגמה נוספת:

class MyClass
  def foo
    puts \'aleph\'
  end
end

x = MyClass.new

class MyClass
  def goo
    puts \'beth\'
  end
end

y = MyClass.new
x.foo # aleph
x.goo # beth
y.foo # aleph
y.goo # beth

הגדרנו את המחלקה MyClass ואז הגדרנו אותה שוב?
הפעולה הזו נקראת ברובי \”re-opening a class\”. הגדרה נוספת של מחלקה לא \”דורסת\” את רישום המחלקה הקיים, אלא גורמת לרישום חדש או נוסף של כל ה members לאותו \”שק\” של מתודות שנקרא MyClass.

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

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

ברובי ניתן, מכל מקום בקוד, לפתוח מחלקה ולהרחיב אותה. למשל – להוסיף מתודה למחלקה Integer.
אני מוצא גמישות זו כמועילה מעט (אולי זה יכול להיות פתרון אלגנטי לכמה מקרי-קצה) מצד אחד, ובעלת פוטנציאל נזק גדול למדי (מתכנתים מסיקים ש\”נכון\” ברובי לפצל מחלקות לכל מיני אזורים, מכל מיני סיבות) – מצד שני.

האם יש יכולת דומה בשפות אחרות?
בג\’אווהסקריפט ניתן לעשות אותו הדבר – שינוי של ה prototype של האובייקט (= בערך מחלקה ברובי) מכל מקום במערכת, וזה נחשבת פרקטיקה לא טובה.
ב #C יש Partial Classes שזה סוג של פיצול מחלקה לכמה קבצים שונים – אבל השימוש הנפוץ הוא שחלק אחד נוצר מ code generation והשני – מתוחזק בצורה ידנית, והם יושבים במבנה הפרוייקט זה לצד זה.

בקיצור:ע\”פ כל קריטריטיון שאני מכיר, כדאי להמנע מלהשתמש ביכולת ה\”פתיחה מחדש של המחלקה\” – ולשמור על יכולת ההתמצאות (orientation) וההבנה הקלה של המערכת. שימוש אחד שיכול להיות סביר להרחבת מופעים והוספת singleton_methods היא unit-testing ו mocking. עדיף קוד שלא דורש זאת – אך יש כמה מצבים שבהם אני מעריך שהייתי שמח להשתמש ביכולות הללו בבדיקות.

מודולים

מודול ברובי הוא מבנה שמקבץ מתודות, שבניגוד למחלקה – אי אפשר לייצר ממנו מופע (instance).
איך משתמשים במתודות הללו? \”מחברים\” את המודול למחלקה (או כמה מחלקות) – והן יקבלו את הפונקציונליות הנוספת. מודולים הם בעצם, מה שנקרא בשפות אחרות mixin.

module NicePrinter
  def putz(msg)
    puts \'[\' + msg + \']\'
  end
end

class MyClass
  include NicePrinter

  def fooz
    putz \'yay!\'
  end
end

MyClass.new.fooz # [yay!]

ניתן לשלב מודול בכמה מחלקות, ולבצע include לכמה מודולים באותה המחלקה (קירוב של \”הורשה מרובה\”).

דרך נוספת לשלב מודול במחלקה הוא בעזרת extends

module NicePrinter
  A = 1
  def putz(msg)
    puts \'[\' + msg + \']\'
  end

  module NiceSpacer
      B = 2
      def add_spaces(str)
        str.scan(/./).join(\' \')
      end
  end
end

class MyClass
  include NicePrinter
  extend NicePrinter::NiceSpacer

  def fooz
    putz MyClass.add_spaces(\'yay!\')
  end
end

x = MyClass.new

x.fooz # [y a y !]
puts MyClass::A # 1
puts MyClass.singleton_class::B # 2
puts MyClass::NiceSpacer::B # 2

בדוגמה הזו עשינו include כמו בדוגמה הקודמת, וגם עשינו extend ל מודול המקונן NiceSpacer (ניתן לעשות extends לכל מודול – פשוט רציתי להראות קינון של מודולים \”על הדרך\”).

למה השתמשנו ב\” ::\” ולא פשוט בנקודה? כי :: הוא ה resolution directive – דרכו מגיעים לקבועי-מחלקה. מודול (מכיוון ששמו מתחיל / חייב להתחיל באות גדולה) הוא קבוע,  – ועל כן זו הדרך הנכונה לגשת אליו. שימוש בנקודה היה זורק Exception.

extend, בניגוד ל include, מוסיף את המתודות שעל המודול להיות class methods. להזכיר: include מוסיף את המתודות שעל המודול להיות instance methods. כנ\”ל לגבי קבועים.

שימו לב שהקבוע B נוסף לנו פעמיים:

• בפעם הראשונה (כרונולוגית) – כחלק מה include: כאשר עשינו include נוספף המודול NicePrinter וכל המודולים המקוננים שלו (במקרה שלנו: NiceSpacer).
• בפעם השניה פעם על המחלקה היחידנית של MyClass – כאשר השתמשנו ב extends

 ברגע שמוסיפים מודול מקונן – אז גם המודול הפנימי נוסף תחת ה namespace המקונן שלו. בדוגמה למעלה בעצם הוספנו את NiceSpacer פעמיים: פעם כמודול מקונן על המחלקה MyClass, ופעם ישירות על המחלקה היחידנית של MyClass. אני מקווה שקריאת ההסבר פעמיים תספיק בכדי לקלוט את העניין… אם לא – פשוט פתחו irb ונסו קצת בעצמכם.

האם יש למודולים עוד תכונות ויכולות? – כן.

ניתן להגדיר צורות שונות של תלויות בין מודולים כך שחיבור של אחד למחלקה (ע\”י include או exclude) בעצם יחבר גם מודולים אחרים, או סתם \”יפתח\” (re-open) את המחלקה שמוסיפה את המודול ויבצע בה שינויים.

יכולות אלו שימושיות מאוד לבניית DSL – אבל כדאי מאוד להיזהר בהן בכתיבת \”תוכנה בסיסית\”. לכו תבינו שמתודה שלכם מתנהגת אחרת כי מודול שנוסף, גרר מודול אחר – שעושה שינוי ב members של המחלקה…
התחכמות (cleverness) ב Metraprogramming של רובי היא סגולה ללילות לבנים ללא שינה. ראו הוזהרתם!

מודולים משמשים גם כ namespace (כמו ב ++C או #C), ניתן לאגד בתוכם מחלקות, פונקציות, וקבועים – תחת שם שלא יתנגש עם מחלקות, פונקציות, וקבועים אחרים:

module MyModule
  class MyOtherClass
    def goo
      puts \'wow!\'
    end
  end
end

class MyClass
  include MyModule
end

x = MyModule::MyOtherClass.new
x.goo # wow!

y = MyClass::MyOtherClass.new
y.goo # wow!

האם ניתן לעשות include ו/או extend גם למודולים כאלו שמכילים מחלקות? – בוודאי. חשבו על Module ומחלקה כ hash (\”שק תכונות\”) שניתן להרכיב אותם (עם כמה מגבלות) אחד על השני.

בדוגמת הקוד ניגשתי פעם ל MyOtherClass דרך המודול כ Namespace, ופעם אחרת כקבוע על המחלקה MyClass. שתי הדרכים אפשריות ותקינות.

מתודות ו\”שליחת הודעות\”

בשונה משפות כמו ג\’אווה / ++C בהם מתייחסים לx.foo כ \”method invocation\”, ברובי (כמו ב Smalltalk או Objective-C) מתייחסים להפעלת מתודות כשליחת הודעות.

למשל:

class MyClass
  def foo
    puts \'yay!\'
  end
end

x = MyClass.new

x.foo # \'yay!\'
x.send :foo # \'yay!\'

קראנו ל foo ב 2 אופנים:

• x.foo היא רמת ההפשטה הגבוהה, \”כאילו\” foo היא תכונה של המופע x.
• x.send :foo היא האופן בו הדברים קורים בפועל ברובי – שליחת הודעה בשם foo ל x.

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

הנה כמה הבדלים עקרוניים:

• ניתן לשלוח כל הודעה (בעזרת המתודה send) שראינו למעלה. זהו בעצם syntactic sugar למה שמתרחש באמת.
• ניתן להענות לכל הודעה, גם ל\”הפעלת\” מתודה שלא הוגדרה מראש במחלקה – ע\”י מימוש המתודה method_missing במחלקה.
• בעזרת method_missing ניתן לעכב הודעות, להתעלם מהודעות, וכו\’.

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

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

הכלי של method_missing מאפשר כח רב ברובי – להענות למתודות שלא הוגדרו מראש על ידי המחלקה.
מימוש ברירת המחדל של method_missing הוא לזרוק exception, והוא נמצא בתוך module בשם kernel ש\”מחובר\” למחלקה Object.

האם שתי דרכי הפעולה זהות?
לא. אם תקחו את הדוגמה למעלה ותהפכו את foo למתודה private – תראו שדרך ההפעלה הראשונה (בעזרת נקודה) – נכשלת, אבל הדרך השניה (send) מצליחה. מדוע?

אכיפת ה visibility ברובי נעשית כאשר משתמשים במנגנון הנקודה, ו send פשוט עוקפת את המנגנון הזה. send היא בעצם מתודה public של המחלקה Object (הבת הישירה של BasicObject) – שתפעיל את send_internal של המפרשן של רובי.
כלומר: ע\”י send ניתן לקרוא, מכל מקום בקוד, למתודות private של מחלקות אחרות. מה עוצר מבעדנו לכתוב קוד שקורא ל private members של מחלקות אחרות ללא מגבלה? – משמעת עצמית בלבד.

בעצם – האם איי פעם שפה מנעה מאיתנו יישום של רעיונות בכך שלא סיפקה לנו כלים מוכנים ליישם אותם? עיכבה – כן, אבל לא מנעה. חשבו כיצד מתכנתי ג\’אווהסקריפט שמיישמים encapsulation בשפה – למרות שהיא לא קיימת ככלי בשפה (למי שלא מכיר: ע\”י דפוס עיצוב בשם Module / Revealing Module או פשוט ע\”י קונבנציה של קו תחתון בתחילת מתודות שהן \”פרטיות\” – ומשמעת שאין לגשת אליהן מבחוץ).

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

הנה ה\”דפוס\” המקובל ליישום ריבוי-צורות ברובי:

class AbstractHerald
  def announce
    raise NotImplementedError, \'You must implement the announce() method\'
  end
end

class OptimisticHerald < AbstractHerald
  def announce
    puts \'life is good!\'
  end
end

class PessimisticHerald < AbstractHerald
  def announce
    puts \'... life sucks!! :(\'
  end
end

x = OptimisticHerald.new
puts x.is_a? AbstractHerald # true
puts x.is_a? Hash # false

האכיפה על כך שנממש את המתודה announce – נמצאת ב runtime (מוזר בג\’אווה, טיפוסי ברובי).
בעזרת ?is_a – אנו יכולים לבדוק אם מופע שביידנו יורש ממחלקה מסויימת.

חשוב להזכיר שנטייה טבעית כשמגיעים לשפה חדשה היא לחפש את המבנים המוכרים. חשוב להיזהר ולא להגזים, לא \”לכתוב ג\’אווה ב syntax של רובי\”. שפת רובי היא דינאמית מאוד מטבעה – וחשוב להבין ולהתרגל לסגנון זה.

מה עם ריבוי ממשקים?
נדמיין לרגע מחלקה בג\’אווה בשם User שניתן לגשת אליה דרך הממשק UserInfo לפעולו ת של קריאת נתונים, ודרך הממשק UserMaintainance – לפעולות עדכון על פרטי המשתמש (היא מממשת את שני הממשקים). המחלקות השונות במערכת מוגבלות לעשות על User רק את מה שהממשק שבידן מאפשר להן – הגבלה שנאכפת ע\”י השפה.

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

כיצד עושים זאת? המתודה ?respond_to בודקת האם מחלקה (וההיררכיה שלה, המודולים שמחוברים אליה, וכו\’) יודעים לטפל במתודה (ע\”פ השם שלה – לא ע\”פ מספר הפרמטרים!).
אם השתמשתם ב method_missing יהיה עליכם לדרוס את המתודה ?respond_to_missing ולהצהיר על אלו מתודות אתם מגיבים – בכדי ש ?respond_to תמשיך לספק תשובה נכונה (מזכיר את equals ו hash בג\’אווה).

puts x.respond_to? :announce # true
puts x.respond_to? :quit_job # false

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

לכאורה, כל פעם שאתם שאתם מקבלים כארגומנט אובייקט אחר שאתם לא בטוחים (כיצד ניתן להיות בטוחים!?) שהוא יודע לענות למתודה מסויימת כלשהי – עליכם לבדוק זאת קודם ע\”י ?respond_to. זה \”תיק\” לא קטן.

בפועל, סביר שתשתמשו ב ?respond_to בנקודות בהן:

• הקוד שלכם נכשל בהן בעבר, והחלטתם \”לחזק\” (hardening) אותן.
  כלומר – הסיבה לתקלה הייתה מורכבת, ולא טעות הקלדה \”טפשית\”.
• בנקודות שהסיכון לתקלה שכזו הוא בהחלט סביר, בהנחה שאתם מתכנתים זהירים / קפדנים.

שווה לומר זאת פעם נוספת: ?respond_to לא תבדוק לאלו פרמטרים המתודה מצפה – אלא רק שקיימת מתודה בשם שצויין. כלומר: הבדיקה היא \”בערך\” ולא לגמרי מדוייקת.

class MyClass
  MyMessage = Struct.new(:source, :target, :text)

  def foo
    some_condition = false
    MyMessage.new(\'a\', \'b\', \'c\') unless some_condition
  end

  def goo
    MyMessage.new \'a\', \'b\'  # text will be nil
  end

end

msg = MyClass.new.foo
puts msg.text, msg.source # c, a

קצת חבל שה IDE בו אני משתמש, RubyMine, לא מספק auto-complete ממשי ל Structs.

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

http://rubymonk.com/learning/books מקור טוב ללמידת רובי לעומק

[א] אם אתם רוצים לראות את שרשרת ההיררכיה של מחלקה – פשוט הפעילו עליה את המתודה ancestors.

[ב] מפתחי ג\’אווה, ענו לעצמכם בכנות: איזה אחוז משגיאות הקוד המשמעותיות הקומפיילר \”תופס\”? ואיזה אחוז הוא לא?