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

1.4. סיבות לשימוש בתכנות מונחה עצמים

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

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

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

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

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

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

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