OOP Methodology

OOP, Why? התפתחות שפות תכנות דור ראשון - שפת מכונה . דור שני Assembly -. דור שלישי - COBOL, Basic, Pascal, Smalltalk, C, C++… . דור רביעי –RAD (VB, Delphi, C#, VB.NET, Java…) הדור השלישי מתאפיין בשפות OOP הראשונות.

OOP, Why? התפתחות המחשבים 1950 – משמשים בעיקר בתעשייה הביטחונית, עיבודים מבוססים Batch, הפצה מאוד מוגבלת, תוכנות מופעלות על ידי מומחים, מדענים וכו'. 1960 – ריבוי משתמשים (Multi-user) , עיבוד מקבילי, מסדי נתונים, חברות אזרחיות מתעניינות במיחשוב. 1970 - מערכות מבוזרות, מחירי החומרה צונחים, כניסה מסיבית יותר לעולם האזרחי, דרישות שונות מהמקובל, משתמשים פחות מקצועיים. 1968 - משרד ההגנה האמריקאי משבר התוכנה

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

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

OOP, Why? תכנות פרוצדוראלי האיור מציג תוכנית המכילה N משתנים ו- N פונקציות. כל אחת מהפונקציות יכולה לגשת לכל אחד מהמשתנים ולקרוא לכל אחת מהפונקציות האחרות בתוכנית, כולם נגישים לכולם ,כולם קריאים לכולם.

OOP, Why? שגיאות לוגית תכנות פרוצדוראלי – בעית תחזוקה ראשונה. תוכנית מכילה כ- 500 משתנים וכ- 5000 פונקציות. נניח שטווח ערכיו החוקי של אחד מהמשתנים המוגדרים בתוכנית הוא בין 1 ל- 100 , בדוחו"ת שהתוכנית מנפיקה המשתנה מכיל את הערך 300 . היכן נמצאת הטעות? , כמה זמן יקח לאתר את המקום המדוייק? כמה זמן יקח לתקן את שגיאה? מהן הסכנות הטמונות בתיקון השגיאה?

OOP, Why? שינויים בתוכנית תכנות פרוצדוראלי – בעית תחזוקה שניה תוכנית מכילה כ- 500 משתנים וכ- 5000 פונקציות. בין שאר המשתנים קימת מחרוזת המייצגת את שם המשתמש (שם פרטי ושם משפחה). קיים צורך להפריד שדה זה לשני שדות נפרדים: אחד עבור שם פרטי והשני עבור שם המשפחה. היכן בקוד צריך לתקן? , כמה זמן יקח לאתר את המקומות המדוייקים? כמה זמן יקח לעדכן את השינויים בקוד? מהן הסכנות הטמונות בעידכון?

האדם אינו אמור להתאים עצמו ולשרת את הטכנולוגיה, OOP, Why? תכנות פרוצדוראלי, פרוצדורעלי או פרוצדורעלי ? האדם אינו אמור להתאים עצמו ולשרת את הטכנולוגיה, הטכנולוגיה היא זו שאמורה להתאים עצמה לאדם ולשרת את צרכיו.

האין זה עוול? OOP, Why? תכנות פרוצדוראלי, פרוצדורעלי או פרוצדורעלי ? התכנות הפרוצדוראלי מחייב את המתכנת לחשוב בצורה ובאופן שהמחשב חושב, המתכנת חייב להתאים עצמו לדרישות ולמבנה של המכונה. האין זה עוול?

OOP, Why? יתרונות צורת חשיבה טבעית יותר לאדם, הטכנולוגיה מתאימה עצמה לאדם ולא להיפך. שימוש במודל הקרוב יותר למציאות האנושית. שימוש חוזר ברכיבים , Reusability . אמינות פיתוח מהיר יותר (?). מקל על עבודה ציוותית בפיתוח תוכנה. תחזוקה פשוטה וזולה יותר בצורה משמעותית.

OOP, Why not? חסרונות איטיות. גודל.

Encapsulation Inheritance Polymorphism OOP, What? כל שפה מונחית אובייקטים חייבת לתמוך בשלושת התכונות הבאות: Encapsulation Inheritance Polymorphism

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

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

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

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

Encapsulation מבנה מחלקה מבנה של מחלקה טיפוסית:

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

Data Members תמיד יוגדרו כ- Private. Encapsulation ערך מוסף – הסתרת מידע לכל חבר מחלקה (Data Members ו- Methods) מוגדרת הרשאת גישה משלו, קיימות מספר הרשאות גישה, השכיחות ביותר הן: Public ו- Private . Private: חברי מחלקה המוגדרים כ- Private הנם פרטיים למחלקה ולכן מוכרים רק על ידי המתודות של המחלקה, מחלקות אחרות אינן יכולות לגשת אליהם לא לצורך קריאת תוכנם ולא לצורך שינוי תוכנם, המחלקות השונות בפרויקט אף לא מודעות לקיומם של הרכיבים הפרטיים בתוך המחלקה. Public: חברי מחלקה המוגדרים כ- Public הנם ציבוריים ולכן הם מוכרים על ידי המחלקות האחרות בפרויקט אשר יכולות לגשת אליהם. על מנת להגן על הנתונים נקפיד על הכלל הבא: Data Members תמיד יוגדרו כ- Private.

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

Encapsulation מבנה תוכנית OOP :

Encapsulation שגיאות לוגית OOP – בעית תחזוקה ראשונה. תוכנית מכילה כ- 500 משתנים וכ- 5000 פונקציות. נניח שטווח ערכיו החוקי של אחד מהמשתנים המוגדרים בתוכנית הוא בין 1 ל- 100 , בדוחו"ת שהתוכנית מנפיקה המשתנה מכיל את הערך 300 . היכן נמצאת הטעות? , כמה זמן יקח לאתר את המקום המדוייק? כמה זמן יקח לתקן את שגיאה? מהן הסכנות הטמונות בתיקון השגיאה?

Encapsulation שינויים בתוכנית OOP – בעית תחזוקה שניה תוכנית מכילה כ- 500 משתנים וכ- 5000 פונקציות. בין שאר המשתנים קימת מחרוזת המייצגת את שם המשתמש (שם פרטי ושם משפחה). קיים צורך להפריד שדה זה לשני שדות נפרדים: אחד עבור שם פרטי והשני עבור שם המשפחה. היכן בקוד צריך לתקן? , כמה זמן יקח לאתר את המקומות המדוייקים? כמה זמן יקח לעדכן את השינויים בקוד? מהן הסכנות הטמונות בעידכון?

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

Encapsulation אובייקט - ההגדרה של Booch : לכל אובייקט יש מזהה (Identity) מצב (State) והתנהגות (Behavior). Identity : לכל אובייקט יש מזהה ייחודי, תפקידו לזהות את האובייקט באופן חד ערכי, על מנת שניתן יהיה להבדיל בין האובייקטים השונים מאותה המחלקה. State : אוסף הערכים של המאפיינים בזמן נתון קובע את ה- State של האובייקט. Behavior : לכל אובייקט מוגדרות אוסף פעילויות , לכל קבוצה של פעילויות ניתן להתייחס כהתנהגות.

Encapsulation אובייקט - ההגדרה של Booch : אירועים חיצוניים יכולים לשנות את ה- State של אובייקט מסויים אולם לא את ה- Identity . לדוגמה: אובייקט המייצג הזמנה מכיל את השדות הבאים: פרטי ההזמנה, תאריך ההזמנה, רשימת מוצרים בהזמנה וסטאטוס. שדה הסטאטוס נשאר פתוח כל עוד ההזמנה לא סופקה ללקוח. ברגע שהלקוח אישר את קבלת ההזמנה האובייקט משנה את ה- State מפתוח לסגור.