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

[ELIVB]

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

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

 

[user32]

תתחיל מההתחלה...

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

 

[ELIVB]

OOP

ובכל זאת האם ניתן להעביר כל קוד לקוד OOP. יש לי תוכנית שמורידה קובץ מסויים(EXCEL) מאינטרנט והופכת אותו לקובץ בסיס נתונים לפי דרישת המשתמש. רוב התכנית זהו קובץ עיבוד ויצירת בסיסי נתונים SQL MDB וכו' כאשר המשתמש רואה את כל השלבים במסך. תודה אלי

 

[hg1979]

תראה

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

 

[משורר התוכנות]

תרשה לי להוסיף

שבעיני היתרון הגדול של OOP הוא בגמישות. לצורך ההשוואה, זה דומה לתקע ושקע חשמליים. לא משנה מה עושה המכשיר החשמלי שלך, כל עוד יש לו תקע "סטנדרטי" הוא יתחבר לרשת. ואותו דבר לגבי USB. עובדה שיש התקני USB הזויים כמו מטען פלאפון, מאוורר ומנורה... ברור שלא לצורך כך המציאו את ה-USB... מה שכן, זה מוכיח שכל עוד ההתקן "מדבר" USB, הוא יכול לעשות מה שרק תרצה. אותו דבר בתוכנה: הרעיון הוא להגדיר ממשקים (interfaces). ככה אפשר בקלות להחליף את ה"מימוש" וכל עוד הרכיב "מדבר" את שפת הממשק, הוא יכול לעשות מה שבא לו. זו לדעתי הבשורה הגדולה של ה-OOP. ואתן מספר דוגמאות מעולם התוכנה: מערכת קבצים (file system) היא דוגמה יפה: פעם זה היה גישה לכונן פיזי. אחר כך אפשר היה לגשת לכונן רשת שנראה "כמו כונן רגיל". גם כונן CD "נראה כמו כונן רגיל". והכי יפה: SAMBA שזה אפשרות לגשת למערכת קבצים של לינוקס שנראית "בדיוק כמו כונן רגיל" של חלונות... אני מניח שתפסת את הרעיון. במקרה שלך למשל, הדבר שהכי נראה לי זה "לעטוף" את פורמט הקבצים מאחורי ממשק. ככה אם היום התמיכה היא רק באקסל, מחר תוכל על ידי אותה תוכנה לייבא "open office" ומחרתיים כל פורמט קבצים אחר. כאן בא לידי ביטוי היתרון של OOP. תזכור: אמרת OOP אמרת הגדרת ממשקים ורכיבים שניתנים להחלפה. בדיוק כמו התקני USB. בהצלחה

 

[hg1979]

מענין

לדעתי הדוגמא שנתת (ממשקים כלליים) היא אולי הכי חשובה מבחינתך אבל לא לגמרי קשורה ל OOP בפרט. ממשקים (או Interfaces בלעז) הם רק אחד מהכלים שסביבה מונחית עצמים מספקת, שוב אולי משום מה הוא הכי חשוב לך או הכי שימושי לך זה עדיין לא משנה את המהות. בתכנות כמו במקצועות אחרים הכי חשוב להחליט באיזה כלי להשתמש לישום המטרה ולאו דווקא להיות מומחה בכלי מסויים. יש משפט שקראתי באנגלית שאולי הכי מתאים פה לנושא (תרגום חופשי) : "כשכל מה שיש לך ביד זה פטיש, הכל מסביבך נראה כמו מסמרים". ובנושא לדוגמאות שנתת על מערכות קבצים ורשתות, במערכות אלה ממש אין קשר לממשקים, OOP או מה שלא יהיה, שם מדובר על שכבות הפשטה, כמו מודל ה OSI של הרשתות שמחלק את הרשת ל 7 שכבות לוגיות, כמו שנהוג בתוכנות קיום לחלק את המערכת ל 2-3 ויותר שכבות.

 

[משורר התוכנות]

אז מה זה OOP עבורך?

"רשמית" OOP מורכב משלושה רעיונות: 1. encapsulation - "עטיפת" פרטי המימוש והסתרתם בתוך האובייקט כדי לא ליצור תלות בין הקוד הקורא לקוד המממש. 2. inheritance - ירושה. מתחלקת לירושת ממשק וירושת מימוש. לרוב לא מבחינים ביניהם, בעיקר בשלבים הראשונייים של ההכרות עם OOP. לגבי ירושת מימוש ישנם הרבה מאמרים שמתארים את מגבלותיה. 3. polimorphism - פולימורפיזם. היכולת של אובייקטים שונים לבצע פעולה שונה כתגובה להפעלת מתודה. למעשה אם נשים לב, גם אם טכנית זה ממומש על ידי ירושה, למעשה יש פה מימוש ממשק. כל אובייקט מממש את המתודה הציבורית (public method היא למעשה חלק מממשק, גם אם לא הוגדרה כך) בצורה שהוא רוצה. העיקר שיקבל ויחזיר את הפרמטרים כפי שהוגדר לו. אז הניסוחים שלעיל קצת מורכבים, בעיקר למי שחדש בתחום, אבל לאחר מספר שנים של נסיון בתחום, אני שם לב ששלושת המרכיבים שלעיל חותרים כולם למטרה המרכזית שלשמה המציאו (לדעתי) את ה-OOP והיא: מיחזור קוד ומודולריות! אם זו לא המטרה, מהי כן המטרה? (ודאי שלא יעילות בביצועים...

)

 

[ELIVB]

OOP

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

 

[ייוניי]

לעבור ל OO

קודם כל אני חושב שכל קוד פרוצדוראלי קיים ניתן להמרה לקוד OO. האם זה כל כך מסובך? לא בטוח אבל זה גם לא כל כך פשוט. אני חושב שהדבר הראשון שצריך לעבוד עליו במעבר כזה הוא זרימת המידע בקוד. חפש את המקומות בקוד שבהם אתה מעביר מידע ממקום למקום. זה יכול להיות העברת פרמטרים לפונקציה, שליפת ערך ממאפיין וכו'... ב OOP אתה אמור להשתדל להעביר כמה שפחות מידע ממקום למקום ובמקומו פשוט להעביר אובייקטים. אתה יכול להתחיל למשל בלקחת פונקציה מסויימת ולהפוך אותה למחלקה על ידי יצירת בנאי שמקבל את כל הפרמטרים שקיבלה הפונקציה והוספת מתודה "בצע" שתבצע את הקוד שביצעה הפונקציה. עכשיו אתה יכול לחפש בקוד שלך את הקריאות לפונקציה המקורית ולהחליף אותן ביצירת אותו אובייקט והרצת מתודת ה"בצע" שלו. השלב הבא והחשוב יותר הוא להתחיל לבדוק אם אותו הקוד שעכשיו יוצר אובייקט ומריץ אותו לא יכול היה פשוט לקבל את האובייקט הזה ממקום אחר. לאט לאט אתה צריך לשאוף להגיע למצב שבוא יש מעט מאוד העברת מידע בין קטעי קוד ויותר העברה של אובייקטים שיודעים לבצע פעולות (שאת המידע לביצוע הפעולות הם מקבלים בבנאי שלהם). נקודה נוספת שאפשר לשפר היא קריאה של מידע ממאפיינים. אתה צריך לשאוף למצב שבוא לא תצטרך לבקש מידע מאובייקט מסויים אלא פשוט תוכל לקרוא למתודה שלו שתבצע את העבודה שעבורה המידע רלוונטי. כלומר, במקום לשאול את האובייקט כמה רשומות נרשמו בינתיים ב DB, ולעדכן את מד ההתקדמות בהתאם, אפשר פשוט להעביר לאובייקט את פקד מד ההתקדמות ושהוא יעדכן אותו בעצמו. זו בערך ההתחלה, בהמשך אפשר להתחיל לשתמש בממשקים על מנת להקטין עוד יותר את התלות בין האובייקטים וככה אתה מתקרב ל OOP. בהצלחה!

 

[hg1979]

כן

שאלת את השאלה בפורום עם דגש גדול יותר על ארכיטקטורה ופילוסופית עבודה מאשר תכנות תכל'ס. מספר הדעות יהיה בערך כמספר המגיבים (אולי יותר

).

 

[ייוניי]

פילוסופיית עבוד

 

[ייוניי]

ארכיטקטורה ופילוסופיית עבודה

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

 

[hg1979]

זה מה שהתכוונתי

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