תכנות מונחה עצמים (OOP) - מבוא תיאורטי

סגור באמצעות טופס זה תוכלו לספר ולהמליץ לחבריכם..
שם השולח:
כתובת דוא"ל של השולח:
שם המקבל:
שלח לכתובת דוא"ל:
הוסף הערה:
מבוא לתכנות מונחה עצמים (OOP - Object Oriented Programming) - מבוא תיאורטי.

תכנות מונחה עצמים (OOP) 
 

מאת: ארז קלר

חלק 2 - מבוא תיאורטי


שיעור בהיסטוריה במסגרתו נפליג אחורה, לרגע קט, לתחילת שנות ה-60, בתקופה זו הטכנולוגיה מתפתחת בקצב מהיר מבעבר, מחשבים הנם מהירים יותר, קטנים יותר, אמינים יותר וזולים יותר.
ההתפתחות הטכנולוגית המואצת באותם השנים, מובילה למהפכה של ממש, המחשבים שהיו עד אז נחלת משרדים ממשלתיים, ומערכות  צבאיות וביטחוניות, נחשקים יותר ויותר על ידי התעשיות האזרחיות.
בתחילת אותו העשור ,התעשיות האזרחיות מתחילות להכיר ביכולת המחשב לשפר תהליכים, להוזילם ולהאיצם, ההתעניינות במחשוב הולכת וגוברת, ומכאן ועד רכישת והטמעת מערכות מחשב הדרך הנה קצרה.
אניאק (ENIAC) - המחשב האלקטרוני הראשון
אניאק (ENIAC) היה המחשב האלקטרוני הראשון  
נוצר ב-1943 על ידי צבא ארצות הברית (התמונה מתוך ויקיפדיה)
 
ואכן, מאמצע שנות ה-60 המחשב חודר לחברות תעשיות אזרחיות רבות.
צרכים ביטחוניים שונים מהותית מצרכים אזרחיים, נדרשו תוכנות שיספקו פתרונות לבעיות בהנדסת ייצור, ניהול עובדים, פיתוח ותכנון מוצרים חדשים, פיתרון בעיות אלגוריתמיות מורכבות, סימולאציות לחוזק חומרים וכו' .
השיפור הטכנולוגי הרב, באותן השנים, מאפשר פיתוח מערכות בעלות מורכבות פונקציונאלית  גדולה מבעבר, הדרישה לתוכניות מחשב גדולות יותר, מורכבות יותר, מהירות יותר ויעילות יותר הולכת וגוברת.
זהות המשתמשים משתנה מקצה לקצה, בארגונים צבאיים המשתמשים הנם ברובם אנשי מקצוע אשר מכירים את קרביו של המחשב ומתקשרים עמו תוך כדי הקלדת פקודות ב"כתב סתרים" המובן רק להם.
בתעשייה, משתמשי המחשב של תקופה זו יכלו להיות אנשי מקצוע כגון: מהנדסי מכונות, מהנדסי כימיה, פיזיקאים, אנשי אקדמיה וכו'. אנשי מקצוע מעולים בתחומם, אולם ללא כל ידע מקצועי בכל הנוגע לשימוש במחשב. כך שנוספת לה דרישה חדשה, תקשורת "אנושית" וידידותית יותר בין המחשב והתוכנות לבין משתמשי הקצה. הרי לא ניתן לדרוש מאותם כימאים, פיזיקאים, מהנדסים, שבנוסף לבעיות המקצועיות המורכבות אשר עמדו בפתחם, יתמקצעו גם בעולם המורכב והלא מובן של המחשבים דאז, הדרישה הייתה פיתוח פתרונות "אנושיים" יותר.
ויצק - המחשב הישראלי הראשון נבנה במכון ויצמן
 
ויצַ‏ק (WEIZAC - Weizmann Automatic Calculator) הוא המחשב הראשון במדינת ישראל 
ואחד המחשבים האלקטרוניים הראשונים בעולם. המחשב, שנבנה במכון ויצמן,
החל לפעול בשנת 1955 (התמונה מתוך ויקיפדיה)
 
אולם, דרישה זו, מוסיפה נפח קוד לא מבוטל, רכיבי ממשק אלו יכולים להכיל נפח קוד די מורכב, למרות שלא דובר עדיין על ממשק משתמש גראפי (GUI) , אלא על הוספת יכולת תקשורת פשוטה וקלה בעלת עקומת למידה קצרה ומתונה.
 
עולם המחשבים, אם כן, נכנס לעידן חדש שבו הדרישות היו גבוהות מבעבר.
מצד אחד האפליקציות היו מורכבות, מסובכות ואנושיות וכפועל יוצא גם גדולות יותר,
ומהצד שני הדרישה הייתה למהירות בפיתוח (עמידה בלוחות זמנים), ולמהירות ויעילות בביצוע (זמן תגובה מהיר, אמינות התוצאות, חיסכון במשאבי חומרה יקרים, יציבות וכו').
וככל שהטכנולוגיה התקדמה, כך גם נדרשה התקדמות רבה במוצרי התוכנה הנלווים.
חברות התוכנה של אותם הימים התקשו לעמוד במשימה, הן לא הצליחו לעמוד בלוחות זמנים, נכשלו בעמידה בתקציבי הפיתוח, התוכנה המוגמרת לא עמדה בציפיות, שגיאות והתרסקויות היו תופעה שכיחה.
על פי אומדנים שונים, בסוף שנות ה- 60 ותחילת שנות ה- 70 הושקעו בארה"ב לבדה כ- 200 מיליארד דולר בשנה בפיתוח אפליקציות מסחריות, אולם רק 5% מהפרויקטים עמדו בציפיות.
בניסיון להשמיש את שאר הפרויקטים, נאלצו חברות הפיתוח לערוך שורה ארוכה של שינויים אשר הובילו לתוצאות כספיות עגומות לאותן החברות. ועדיין, למרות מקצה השיפורים הנוסף רוב הפרויקטים כשלו, רובם נזנחו ולא נכנסו לשימוש מעולם.
 
ה"יציאה מהארון" של עולם המחשבים מהעולם הממשלתי/ביטחוני לעולם העסקים לוותה בקשיים רבים,משבר התוכנה סכומי עתק ירדו לטמיון, הפסדים כספיים נגרמו לחברות התוכנה וללקוחותיהן, כגודל הציפיות כך גודל האכזבות.
זו התפאורה המלווה את עולם ה"היי טק" של סוף שנות ה- 60 ותחילת שנות ה- 70,
תקופה אשר מכונה "משבר התוכנה" (Software Crisis).
ובעקבות כך, חברות רבות זנחו (או דחו לזמנים טובים יותר) את רעיון המחשוב, 
חברות נוספות חדלו להאמין שהמחשב מסוגל להתמודד עם הבעיות היומיומיות שלהן.
 
מנגד, התעוררה חשיבה שונה. במרכזה הטענה שיתכן וניתן יהיה להתמודד עם הקשיים והתקלות באמצעות טכניקות פיתוח אחרות מהמקובל באותה תקופה.
הטכניקה המקובלת באותם ימים הייתה התכנות הפרוצדוראלי.  
תכנות פרוצדוראלי 
בתכנות פרוצדוראלי קיימת הפרדה בין המידע לבין הפונקציונאליות של התוכנית, הדגש בטכניקה זו מושם על החלוקה לפונקציות, המידע מועבר מפונקציה לפונקציה עד לקבלת הפלט.
 
תפקיד הפונקציות הנו לבצע פעולות על המידע, פונקציה הנה יחידת ביצוע בעלת תפקיד מוגדר. כאשר התפקיד המוגדר מורכב, מחולקת הפונקציה לתתי פונקציות, ואם גם הן מורכבות (מה שבדרך כלל קורה) , אז גם הפונקציונאליות של אותן תתי הפונקציות מחולקת בין תת תתי פונקציות וחוזר חלילה, עד שמגיעים לאוסף של פונקציות "אטומיות", דהיינו, פונקציות המבצעות פעולה בודדה ופשוטה .
מה קורה למידע בתהליך זה? ,
המידע מועבר מפונקציה לפונקציה, אשר בתורה מעבירה אותו לתתי הפונקציות אשר היא מפעילה, וכל אחת מאותן תתי פונקציות מעבירה ..... וחוזר חלילה.
נשמע מסובך? חישבו על תוכניות המכילות מאות פונקציות, אלפי פונקציות, ואף יותר.
יכולת השליטה הולכת ופוחתת.
המידע אינו מרוכז במקום כלשהו, המידע אינו שייך לאיזו שהיא ישות מוגדרת בתוכנית, לעיתים קרובות, מרוב עומס, נשכח מהו התפקיד של משתנה זה או אחר, במקרים אחרים נשכח אף קיומו של אותו משתנה (ויתכן והוא יוגדר מחדש,ונקבל כפילות מידע בתוכנית).
כאשר נקבל שגיאה לוגית (נניח age = -17) , וננסה לחפש את המקור לשגיאה נמצא את עצמנו צוללים לתוך מספר רב של פונקציות ובודקים את תוכנן. תיקון המקור לתקלה, לאחר שהוא כבר אותר (במידה ואותר) יכול לגרור שגיאות נוספות.
 
המבנה של טכניקת תכנות זו מותאם למבנה המחשב ולטכניקה בה הוא פועל, אולם טכניקה זו הנה זרה לחשיבה האנושית.
 
במידה ואנסה לתאר מבנה תוכנית פרוצדוראלית באמצעות איור, לא מן הנמנע שהיא תתואר כמו באיור הבא:  
דיאגרצה של תכנות פרוצדוראלי - Procedural Programming Diagram
האיור מציג תוכנית המכילה N משתנים ו- N פונקציות. כל אחת מהפונקציות יכולה לגשת לכל אחד מהמשתנים ולקרוא לכל אחת מהפונקציות האחרות בתוכנית, כולם נגישים לכולם ,כולם קריאים לכולם.
 
מצד אחד ניתן לברך על הגמישות שטכניקה זו מספקת למפתחים, מצד שני כאשר ננסה לתחזק אפליקציה כזו נכיר את צידה האפל של הגמישות המוצעת בה.
הצד האפל מתבטא בקשים רבים בשימוש חוזר בקוד כתוב (Reusability), במציאת ותיקון באגים ובהרחבת הקוד הקיים.
במהלך השנים שופרה המתודולוגיה הפרוצדוראלית, שפות פרוצדוראליות רבות הוסיפו מודולים או ספריות, כל מודול התמחה בטיפול בממד מוגדר של התוכנית.
תחילה המדד לחלוקה היה תפקיד הפונקציה, בשנים האחרונות המודולים מורכבים ממבנים ומפונקציות המטפלות באותו המבנה.
החלוקה למודולים שיפרה את קריאות התוכנית, קל יותר למצוא באגים וקל יותר לנצל מודולים קיימים בפרויקטים חדשים.  
המבנה המודולארי אמנם מקל, אולם עדיין המלאכה אינה קלה ופשוטה.     

Object Oriented Programming 
 
מנגד, התעוררה חשיבה שונה.

במהלך שנות ה-70 החלה להתפתח מתודולוגית פיתוח חדשה אשר ניסתה לתת מענה לבעיות אשר הובילו את עולם המחשבים ל"משבר התוכנה" . בבסיסה של מתודולוגיה זו עמדה ההכרה שיש לשנות את התפיסה שמפתחים צריכים להתאים את עצמם לדרך הפעולה של המחשב.
ראשוני המתודולוגים של OOP טענו שיש להתאים את טכניקת הפיתוח לצורת החשיבה האנושית. כך יהיה קל וטבעי יותר עבור האדם לפתח אפליקציות מסחריות בהיקף גדול.
הטענה הייתה שיש להתאים את המכונות לאדם ולא לשנות את האדם לטובת המכונות.
 
ומהם מרכיבי התפיסה האנושית? , על פי אותם חלוצים החשיבה האנושית מתבססת על עצמים (Object, עט, מחשב, עץ, אדם, מזלג וכו' ), מושגים מופשטים (ציון, תפקיד, רעיון, פגישה, הסכם, חוזה וכו'), ושיוכים (סטריאוטיפים, שיוך אובייקט לקטגוריה המספקת אינפורמציה ראשונית ובסיסית על מהותו ותפקידו של האובייקט, לדוגמה: אופניים, מכוניות, מטוסים, רכבות הנם כלי תחבורה. תפוז, אגס, תפוח, בננה הנם פירות וכו').
כאשר אנו מתארים אובייקט במציאות איננו מסתפקים אך ורק בתיאור הפיזי שלו (כיצד הוא נראה, כמה הוא שוקל, מהם מידותיו, מי היצרן אשר בנה אותו וכו') משום שהוא אינו מספק, לכן בנוסף אנו משייכים לאובייקט פעולות (נסיעה, רכיבה, כתיבה, הדפסה וכו').
בצורה זו קל לאדם להתמודד עם כמות המידע האדירה המציפה אותו כל העת, בצורה זו האינפורמציה מאורגנת ומסודרת במוחנו וניתנת לשליפה במהירות כאשר אנו זקוקים לה.
למען האמת, ללא שיטת חשיבה זו יתכן והתקשורת האנושית לא יכלה הייתה להתקיים, כאשר אדם מספר לבן שיחו על מחשב חדש שהוא רכש, אין צורך לתאר ולפרט פרטים שהם ברורים מראש, בן השיח יודע מהו מחשב, הוא יודע שמחשב מכיל מעבד, זיכרון, HD וכו'. 
 
בבסיסה של התפיסה מונחית האובייקטים עומד רעיון זהה, תהליך הפיתוח הנו בניית "עולם מושגים" מבוסס אובייקטים, מושגים, ושיוכים.
על מנת לאפשר את בניית "עולם המושגים" המתואר למעלה ,כל שפה מונחית אובייקטים חייבת לתמוך בשלושה מרכיבים מרכזיים :
 
Encapsulation
Inheritance                                  Polymorphism
 
 
 


 

כל הזכויות שמורות למחבר ©