תכנות מונחה עצמים

3.3.1. האם נרצה שמחלקה תהיה אובייקט?

מחלקה – אחד המושגים החשובים ביותר של התכנות מונחה העצמים.

האם היינו רוצים להפוך מחלקה לאובייקט? איזה סיבות יכולות להיות לכך?

• ctor – מחלקה היא תבנית ליצירת אובייקטים. מי ייצור את האובייקט החדשה? ניתן לחשוב שאובייקט מקבל הודעה ונולד – אולם לפי גישה זו, האובייקט מקבל הודעה עוד לפני שהוא נוצר. יותר טבעי לחשוב כאילו מחלקה היא אובייקט – והיא תקבל הודעה לייצור אובייקט חדש.
• Dynamic dispatch – הודעה m מועברת לאובייקט – בתלות האובייקט צריך להגיב. צריך לקבוע מי מחשב עבור m + אובייקט איזו מתודה תופעל. התנהגות ופרוטוקול משותפים לכל האובייקטים של אותה המחלקה  - ולכן נרצה שה-dispatcher יהיה במחלקה – במקום אחד לכל אובייקט שבזיכרון.
• Garbage allocation – בדומה להודעה – מגיע למקום בזיכרון וצריך לדעת מה נמצא שם. יש טעם שהמחלקה שלהם ("המפה שלהם") תהיה במקום מסוים בזיכרון – ולכן יש טעם שהמחלקה תהיה אובייקט.

• deepcopy, clone, save to file – פעולות אלו צריכות לאתר את מבנה האובייקט ("מפה"). המבנה משותף לכל האובייקטים של אותה מחלקה ולכן יהיה שימושי גם במקרה זה לשמור את המחלקה כאובייקט.

מכל נקודות אלו נראה כי יש יתרונות אם נבחר לייצג מחלקה בתור אובייקט.

מתעוררת השאלה: לאיזו מחלקה שייך אובייקט מסוג מחלקה?

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