Don't Ask – Tell: חשיבה נכונה ב־OOP

Don’t Ask – Tell

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

Don’t ask the object who has the data for the data you need to do the job.
Ask the object who has the data to do the job.

זהו עיקרון תכנוני עמוק, שלמרבה הצער רבים לא מיישמים — ולעיתים אף לא נחשפים אליו כלל.

כאשר אובייקט מחזיק נתונים:

במקום זאת: ⬅️ מבקשים מהאובייקט עצמו לבצע את הפעולה.

כלומר — עובדים עם התנהגות, לא עם מבנה פנימי.

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

הפשטה אמיתית אינה רק “הסתרת מימוש”, אלא:

התמקדות במה שאובייקט יודע לעשות
ולא במה שהוא מכיל

כאשר הקוד משתמש ב־

order.CalculateTotal();

ולא ב־

CalculateTotal(order.Items, order.Discount, order.TaxRate);

הקוד:

זו הפשטה נכונה.

הכמסה אינה מסתכמת ב־private.

היא מתבטאת בכך ש:

כאשר שולפים נתונים ומעבירים אותם בין פונקציות — הכמסה נשברת, גם אם כל השדות מוגדרים private.

המשפט Don’t Ask – Tell מגדיר כלל זהב:

פעולה צריכה להיות ממוקמת באובייקט שמחזיק את הידע הדרוש לביצועה

לא:

אלא:

❌ גישה פרוצדורלית במסווה OOP:

double area = Geometry.Area(rect.Width, rect.Height);

✔️ חשיבה מונחית־עצמים:

double area = rect.Area();

לא בגלל נוחות — אלא כי האחריות לחישוב השטח שייכת למלבן.

אם פעולה צריכה לדעת יותר מדי על האובייקט — היא כנראה לא נמצאת במקום הנכון.

למרבה הצער, עקרונות החשיבה הללו — חשיבה נכונה במונחי OOP — כמעט ואינם נלמדים כחלק מהתוכנית הפורמלית.

סטודנטים ותלמידים לומדים:

אבל לא לומדים לחשוב במונחים של אחריות, התנהגות והצבת לוגיקה במקום הנכון. וכך נוצר קוד שנראה “מונחה־עצמים” — אך חושב ומתנהג כמו קוד פרוצדורלי.

ב־OOP:

לא עובדים עם נתונים

עובדים עם אובייקטים שמבצעים פעולות

Don’t Ask – Tell אינו סיסמה — אלא אבן יסוד של תכנון נכון.