שיחה:תכנות מונחה-עצמים

היסטוריה עריכה

מי האדם או החברה שהגו לראשונה את התכנות מונחה עצמים ? אם תכנות מונחה עצמים מועיל כ"כ לעולם התכנה ומאפשר פיתוח תכנות ברמת מרכבות נמוכה (יחסית לתכנות מודולרי) ויכולת תחזוקת ורה-שימוש תכנתי מדוע לא התפתח סוג תכנותי זה מוקדם יותר ?

הרחבתי את סעיף ההיסטוריה בערך זה, כדי לתת מענה לשאלתך הראשונה. אני מקווה שקריאת סעיף זה וכן קריאת הערך שפת תכנות יתנו מענה סביר גם לשאלתך השנייה, אם כי מענה מקיף יותר יינתן בערך המצאה (כאשר יהיה מי שיכתוב אותו), שבו יוצג התהליך הממושך של התפתחותו של רעיון ומעברו מהמעבדה לשימוש נרחב. דוד שי 23:33, 24 אפר' 2004 (UTC)

תכנות מונחה עצמים משמש, שלב נוסף לפתור את צואר הבקבוק של פיתוח תוכנה.
באבולוציה של פיתוח ישומי מחשב, מחיר החומרה (מעבדים, התקני איחסון) הלך וירד במקביל לעליה מטאורית בביצועים, תוכנות התשתית (פרוטוקלי תקשורת, מערכות הפעלה) הצטמצמו במספרן וגם הן התכנסו לכמה סטנדרטים, התוכנות המשרדיות התנהגו כנ"ל והתוכנה היישומית נותרה צואר בקבוק: מחירה יותר ממה שציפית, זמן הפיתוח גלש ובסוף היום קיבלת לא מאת ה שביקשת, זה תיאור קצת אפוקליפטי אבל הכונה ברורה.
אחד מהמחשבות לטפל בבעייה היה לבסס את פיתוח התוכנה על מודולות, כעין "קופסאות שחורות" שניתן להשתמש בהן שימוש משותף ולהעתיקן ליישומים נוספים, בבחינת שימוש חוזר (Reuse) של קוד ובכך לקצר את תהליך פיתוח תוכנה.
. בהסבר פשטני מאד, תכנות מונחה עצמים הוא תכנות שמבוסס על יצירת "קופסאות שחורות" ("עצמים").ד. גולדמן 19:07, 25 דצמ' 2004 (UTC)

ומדוע אינך כותב זאת בגוף הערך? דוד שי 04:00, 26 דצמ' 2004 (UTC)

למה רק VB.NET? עריכה

מה ההבדל בין התמיכה של VB6 במחלקות (שמאפשר את כל התכונות שצויינו בערך) לתמיכה של VB.NET שע"פ הערך רק היא תומכת בתכנות מונחה עצמים?

אמנם ישנה תמיכה במחלקות בVB6, ואפשר ליצור עצמים, אבל אין תמיכה בקוד לא בירושה ולא בפולימורפיזם. כך שמדובר בחצי תכנות מונחה עצמים. דבר שתוקן בVB.NET. --אפי ב. 10:44, 28 אפר' 2005 (UTC)

נחמד, אבל... עריכה

ישנן מספר תפישות המשלימות זו את זו לגבי תכנות מונחה עצמים:

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

אגב, coupling זה צימוד ולא "תלות". ‏conio.h ‏• ‏שיחה‏ 22:18, 1 אפריל 2006 (UTC)


הסטוריה עריכה

את פיסקת היסטוריה אולי כדאי להעביר לתחילת הערך ליד או ביחד עם פסקת הרקע. בסוף זה קצת תקוע. --אפי ב.שיחה • 11:47, 14 אפריל 2006 (UTC)

זו העצם של הכלב עריכה

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

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

סלחו לי אבל כל פסקת הביקורת חייבת להימחק! עריכה

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

  1. "חוסר התלות בין העצמים גורמת פעמים רבות לכפילויות" - תכנות מונחה עצמים בדיוק בא לבטל את חוסר התלות בין העצמים כדי לא לגרום לכפילויות! לדוגמא כמו שממשיך המבקר ואומר שאם יש פונקציה שמתקיימת בכמה אובייקטים, אזי אותם אובייקטים יירשו ממחלקה שמממשת את הפונקציה הזאת, ויצביעו עליה (מה VTBL) ולכן הקוד לא מוכפל אלא נשמר פעם אחת בזיכרון! בלי שום ניפוח התוכנה וניצול לא יעיל.
  2. "חברות תוכנה משתדלות לעתים קרובות לדחוס לאובייקטים שלהן מאפיינים ופעולות רבות" - זוהי ביקורת בכלל כנגד תכנות מסוים של חברות, ולא תכנות מונחה עצמים נכון!. בתכנות נכון מחלקה אמורה לבצע דבר עיקרי אחד, וברגע שהיא מבצעת יותר מדי דברים מפצלים אותה לכמה מחלקות כדי לא ליצור מה שנקרא God object.
  3. "הדבר גורם לתוצר סופי שעיקר ההשקעה בו מופנית כלפי היכולת לתחזק את הקוד ולשנותו בעתיד, במקום באיכות הנוכחית שלו" - כמי שמכיר את שני צידי המתרס - תכנות פרוצידוראלי ותכנות מונחה עצמים - יודע כמה קשה לתחזק את קוד הנכתב בתכנות פרוצידוראלי וכמה נוחות מספק תכנות מונחה עצמים בתחזוק נכון ויעיל של הקוד, מעצם זה שהוא נהיר יותר לבני אדם, שהלוגיקה שלו יותר נכונה, וכהנה וכהנה.

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

אני זה שהוסיף את פסקת הביקורת, והנה התשובות לבעיות שהעלית:

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

לסיום, יש לי ניסיון של יותר מ-10 שנים בשפות תכנות רבות, ביניהן אסמבלר (תחת מספר סוגי מעבדים ומערכות הפעלה), סי/סי++, רוב שפות האינטרנט, גאווה ועוד. אני מחזיר את הקטע עד שהדיון יגיע לנקודת הסכמה, ואם אתה עונה לתגובה הזאת בבקשה בלי התייחסויות אליי אישית ובלי התלהמות. אני אשמח לשמוע הערות על מה שכתבתי אבל אני לא חושב שעצם קיום הביקורת הזאת נתון במחלוקת. לימון לימון 22:36, 31 ביולי 2007 (IDT)תגובה

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

  1. כתוב The factual accuracy of this section is disputed, פלוס הפנייה לדף השיחה (שאני ממליץ לך בחום לקרוא גם אותה).
  2. כל נקודת ביקורת בפסקה מגובה בהפניה למאמר, בצירוף המילים "/X states/suggested/showed" ואלו אנשים מומחים ולא משתמש לימון לימון עם כל הכבוד.

ובעקבות כך שוב אני מוחק את פסקת הביקורת שלך, אם אתה רוצה להחזיר אותה אנא צרף הפניות למאמרים, ואולי אף לאלה שמצויים בערך באנגלית, כל עוד לא תעשה זאת, זו אינה הבמה עבורך לרשום דעות. עוז ברזילאי 11:30, 2 באוגוסט 2007 (IDT)

אז מה שמפריע לך בסעיף הזה הוא רק שהטענות לא מגובות במאמרים מדעיים? אפשר להסכים שראוי להיות סעיף של ביקורת ושהטענות שמצויות בו כרגע הן סבירות?
צר לי, אבל אין לי את הזמן, הכסף או העניין לקרוא מגזינים שבועיים בתחום או להיות מעורה בו ברמה כזאת, המאמרים היחידים שקראתי היו מפרטים שהיו דרושים לי עבור תוכנות שכתבתי. למרות זאת, זה לא נכון לומר שכתבתי את עמדתי ועמדתי בלבד, את הטענות האלה שמעתי גם ממספר מתכנתים ומנהלים. בכל מקרה, נשמע שאתה קרוב לנושא הזה הרבה יותר ממני, אולי אתה מוכן לשפר את הסעיף הזה ולהוסיף לו הפניות מתאימות? לימון לימון 12:48, 2 באוגוסט 2007 (IDT)תגובה
היי, אני יודע שאני לא קשור (אני גם לא מחובר למשתמש שלי אז בכלל), אבל האמתי שאישית אני לא מת על סעיף הזה... לא שאני ממש יכול לעזור בעצמי, שכן אני לא ממש מבין בנושא - אבל ההיתי שמח לבקש ממישהו לעשות משהו בנושא.
הסרתי את פסקת הביקורת, בעקבות הנימוקים שניתנו לעיל. דוד שי 20:19, 7 באוקטובר 2007 (IST)תגובה

האם קיימת ביקורת על OOP? עריכה

קראתי את גרסת הערך שכוללת בסופה את פסקת הביקורת והתרשמתי שבביקורת יש טעם. עקב כך ביצעתי בגוגל חיפוש על המילים oop criticism תוצאות החיפוש לעיונכם.

ראה את en:Object-oriented programming#Criticism ותבין איך צריכה להיראות פסקת ביקורת. דוד שי 07:21, 12 באוקטובר 2007 (IST)תגובה
על פסקת הביקורת שנמחקה נכתב, "דעה של מישהו שגם טועה וגם מטעה... שטות אחת גדולה... בלון מלא באוויר חם של מישהו שכנראה לא תכנת מימיו בתכנות מונחה עצמים". התבטאויות אלו היו מיותרות ולדעתי גם שגויות. הדרישה לייחוס/ציטוט, שאליה אני מניח כוונתך בלינק שנתת, מקובלת.
כן, הדרישה לייחוס/ציטוט, זו כל כוונתי. בהיעדר אסמכתאות, אין כל צורך לדון בתוכנה של הביקורת שנמחקה. דוד שי 13:20, 12 באוקטובר 2007 (IST)תגובה
איזה סוג של מקורות ייחשבו מספקים לצורך העניין...? מאמרים מהאינטרנט זה בסדר...? אם לא, אין לי איך לייחס מקורות למה שכתבתי כי מדובר בידע אישי שצברתי במהלך השנים ואני לא יודע איפה לחפש לו סימוכין. אם זה לא נחשב כאן לגיטימי לכתוב על סמך ידע אישי, כנראה שבאמת אין מקום לסעיף הזה. יהיה נחמד אם מישהו שמתמצא בעניינים האלה יוכל אולי לכתוב את הסעיף הזה מחדש בצירוף המקורות הנדרשים, כי חבל שיימנע מהקורא מידע חשוב שהופך את הערך הזה לנייטרלי. לימון לימון 06:00, 14 באוקטובר 2007 (IST)תגובה
מאמרים של בני סמכא שפורסמו באינטרנט הם מקורות מצוינים. בלוגים אינם מקורות טובים. אפשר להתחיל בתרגום הסעיף מוויקי האנגלית. דוד שי 06:42, 14 באוקטובר 2007 (IST)תגובה
התחלתי לתרגם מוויקי האנגלית, אבל התוצאה מאכזבת מאוד, משום שמדובר בדברי ביקורת כלליים ביותר, שמעידים יותר על חוסר ההתלהבות של הדובר מאשר על בעיה ספציפית שניתן לדון בה. את דבריו של דייקסטרה לא תרגמתי - אף שהם משעשעים, הם אינם מתייחסים דווקא ל-OOP, אלא לז'רגון של ענף המחשוב, ולאוניברסיטאות החמדניות שממהרות לספק לציבור את הסחורה שהוא מחפש. אמצא מקום אחר לשים אותם. מי שכתב את סעיף הביקורת בוויקי האנגלית היה במצוקה אמיתית אם בחר לצטט את דייקסטרה בהקשר זה. צריך למצוא מקורות לביקורת ממוקדת, ובכך לא ניוושע מוויקי האנגלית. דוד שי 07:05, 14 באוקטובר 2007 (IST)תגובה
במחשבה נוספת, מחקתי את כל מה שתרגמתי, מפני שבביקורת זו מתקיים במובהק הכשל של פנייה אל הסמכות - איש חשוב עיקם את האף, כך לא כותבים ביקורת. דוד שי 07:30, 14 באוקטובר 2007 (IST)תגובה
כאן ניתן למצוא ביקורת רבה ומגוונת, כולל קישורים חיצוניים רבים רבים. הביקורת היא כמעט אלמונית, כך שפנייה אל הסמכות ודאי אין בה, אך יש צורך לבדוק שנכונות כן יש בה. ‏odedee שיחה 07:36, 14 באוקטובר 2007 (IST)תגובה
בפסקת ביקורת ראוי להביא את דעתה של הסמכות, אבל עליה להיות מנומקת, ולא די בעקימת אף בלבד. אני מקווה שבמקור שהביא odedee יש גם ביקורות מנומקות היטב. דוד שי 08:16, 14 באוקטובר 2007 (IST)תגובה
המקור נהדר ומנומק היטב, אבל מרפרוף ראשוני באתר וחיפוש בגוגל על "Findy Services" ו"B Jacobs" לא ברור עד כמה סמכות אפשר לייחס למחבר. במבט ראשוני ולפי מאמרים אחרים באתר נראה שמדובר באדם אחד, ש(כמוני) פשוט נהיה מתוסכל עם הזמן מתמיכה נלהבת וכמעט עיוורת בטענות ושיטות עבודה נפוצות בתחום של פיתוח תוכנה (OOP, SQL...). זה עדיין נחשב מקור אמין שאפשר לכתוב לפיו סעיף ביקורת? לימון לימון 21:46, 14 באוקטובר 2007 (IST)תגובה

אובייקט (תכנות) עריכה

יש סיבה כלשהי (אולי החלטה קודמת) שערך עם שם כדוגמת אובייקט (תכנות) נעדר מרשימת הפירושונים של אובייקט (שכמה דפים מקשרים אליו)? מופיעה שם שורה שמתארת את ההקשר, אך ללא "הזמנה" ליצור ערך כזה. אם אין סיבה שלא ליצור את הערך, האם זהו השם המתאים, או שקיימת חלופה עברית סבירה אחרת כלשהי? שרשרשיחה 23:05, 4 בינואר 2009 (IST)תגובה

נראה לי שאפשר ליצור הפנייה מאובייקט (תכנות) לתכנות מונחה עצמים. גם כתיבת ערך נפרד אובייקט (תכנות) והוספתו לרשימת הפרושונים היא אפשרות סבירה.אורי מוסנזון - שיחה 07:56, 5 בינואר 2009 (IST)תגובה
הערך en:Object (computer science) בויקי האנגלית מתאר את המושג אובייקט בראיה רחבה יותר מתכנות מונחה עצמים, כך שהפניה כזו בכל מקרה לא תוכל לחול עם הסוגריים "(תכנות)" אלא עם משהו ספציפי יותר. שרשרשיחה 21:16, 5 בינואר 2009 (IST)תגובה
כל המונחים בתחום לא נראים לי יצוקים בסלע. אפשר כך ואפשר כך. אם תבחר לתרגם את הערך האנגלי זה עשוי להיות מועיל.אורי מוסנזון - שיחה 00:42, 6 בינואר 2009 (IST)תגובה

שם הערך - נדרש מקף עריכה

היי, צריך להיות: תכנות מונחה-עצמים. היינו, שהעצמים מנחים אותו. הכלל הלשוני הזה חל לא רק בעברית אלא גם באנגלית, ושם לא טעו: en:Object-oriented programming.‏ /Orrlingשיחה 23:10, 11 במאי 2011◄יחד נשמור על ערכינו המשותפים

יותר מדי מוכוון ג'אווה \ ++C עריכה

המאפיינים הבסיסיים של תכנות מונחה עצמים הם

  • חיפוש דינאמי (Dynamic Lookup). כאן מתייחסים אליו בתור "פולימורפיזם", אבל השניים אינם זהים - פולימורפיזם הוא מונח כללי יותר. משמעותו היא שקריאה לשיטה שניתנת לדריסה (virtual ב ++C) נפתרת בזמן ריצה. נובע מזה גם פולימורפיזם.
  • הפשטה (כאן מתייחסים אליה בתור "כימוס". נניח).
  • ירושה - שהיא ירושה של מימוש ולא (רק) של ממשק. דוגמה לירושה שאיננה כוללת ממשק היא ירושה פרטית ב++C.
  • תת-טיפוסים (Subtyping. תרגום בעייתי ואני אשמח להצעות אחרות). כאן מערבבים בין זה לבין ירושה. טיפוס B הוא תת-טיפוס של טיפוס A אםם הממשק של A מוכל בממשק של B. יש דרכים שונות להשיג את האפקט הזה. ירושה היא הנפוצה שבהם אבל לא היחידה; בפייתון, לדוגמה, אפשר פשוט להגדיר פונקציות בעלות אותו שם במחלקה אחרת, וזהו.

בגלל שבג'אווה המונחים subtyping וירושה באים תמיד תמיד ביחד, וגם ב++C זה מובחן רק לעתים נדירות, אנשים הפסיקו להבחין ביניהם. לפירוט אני מפנה לספר Concepts In Programming Languages של John C. Mitchell (המרצה בקורס שפות תכנות של אוניברסיטת סטאנפורד. הספר הוא גם ספר הקורס של שפות תכנות בטכניון, ובמקומות נוספים). הערות? --אלעזר - שיחה 14:51, 6 בספטמבר 2011 (IDT)תגובה

לא הבנתי את המשפט הבא עריכה

"ירושה כזאת עלולה ליצור בעיות במקרה של "ירושת יהלום", כלומר מקרה בו שתיים ממחלקות הבסיס יורשות מאותה מחלקה" מה הדיוק הבעיה? שוויק - שיחה 13:45, 15 בפברואר 2012 (IST)תגובה

הבעיה היא שירושה כזאת עלולה ליצור כפילות של המשתנים במחלקת הבסיס המשותפת, וכן כפילות של שיטות. ויש עוד כל מיני בעיות. לדוגמה:
נניח A יורש מB1 וגם מB2 ששתיהן יורשות מD. ונניח שהמחלקה A מגדירה פונקציה (וירטואלית) foo, שנדרסת גם על ידי B1 וגם על ידי B2. כעת מתוך A אני מבצע קריאה לfoo. לאיזו פונקציה הוא יקרא? כל פונקציה שתיקרא לא תבצע את כל העבודה שאמורה להתבצע, על פי המובן הטבעי של ירושה.
יש לזה כל מיני פתרונות - ב++C יש דבר שנקרא "ירושה וירטואלית", למשל, שגורם לזה שמחלקת הבסיס לא תשתכפל; בפייתון מוגדר סדר מסויים של קריאות כך שבעצם קוראים לכל הפונקציות foo - אבל לכל פתרון יש בעיות משלו.
ראה ירושת יהלום ב(אנ') --אלעזר - שיחה 15:16, 15 בפברואר 2012 (IST)תגובה

יש לפשט את הפתיח עריכה

בברכה, ‏Ben-Natan‏ • שיחה 12:55, 25 בינואר 2015 (IST)תגובה

נמצאו קישורים חיצוניים שצריכים תיקון (יוני 2023) עריכה

שלום עורכים יקרים,

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

כאשר תסיימו לערוך את השינויים הנדרשים, אנא בקרו בדף השו"ת למידע נוסף לתיקון בעיות עם הקישורים לעיל.

הודעה זו תופיע רק פעם אחת לקישורים אלו.

בידידות.—InternetArchiveBot (דווח על באג) 18:49, 18 ביוני 2023 (IDT)תגובה

חזרה לדף "תכנות מונחה-עצמים".