Final Class 15 OOP FTW

הנושא היום: פרדיגמות בתכנות מונחה עצמים (Object Oriented Paradigm)בהשתתפות יונתן, איתי, ערן, אורי, ישי ורן.  לאחר דיון קצר בניסיון לזהות ממתי המונח קיים ומה היו השפות הראשונות בתחום, הזכרנו מספר תכונות חשובות של שפות object oriented כמו:Encapsulation, Inheritance, Polymorphism .דנו על "מנגנון ניהול השיחה" עם האובייקטים, הידוע בשם Polymorphism (מנגנון המאפשר להגדיר לפונקציות באובייקט מבנה ומימוש שונה). על תרומת מבנה האובייקט ליכולת מידול קלה ופשטנית יותר של תוכנה ותקשורת בין רכיבים שונים של התוכנה (אובייקטים). דנו על הניווט בין הודעות ו"יכולות שיחה" הנחשפים על ידי כל אובייקט (פונקציות/מתודות) גם אם לא בהכרח יודעים מהו המימוש הפנימי שלהן, ועל הקלות היחסית של הוספת מימוש חדש או שינוי מימוש קיים.הזכרנו מספר שפות תכנות מונחה עצמים שבהן הגדרות העצמים הן סטטיות (עושות שימוש בהגדרת Class), כגון: C++, Java, C#, ולעומתן הזכרנו אתJavascript שיש לה תכונת prototyping מפותחת ואשר למעשה לא עושה שימוש ב-Classes אלא מתבססת על אובייקטים אשר ניתן לשנות אותם באופן דינמי.סיבוכיות השפה: דיברנו על כך שהשימוש בשפות מונחות עצמים נועד לפשט דברים על ידי מתן כלים לשימוש חוזר בקוד ושימוש בכל התכונות שהזכרנו (ניתנה גם דוגמה לבעיית סידור 8 מלכות על לוח שחמט אשר פתרונה נראה משמעותית פשוט יותר כאשר משתמשים ב-object oriented). לעומת זאת הזכרנו גם שמעבר להפשטה, השימוש בשפות גם יוצר לפעמים סיבוך בכתיבת והבנת הקוד, אשר אינו תמיד חד משמעי וברור כמו שניתן לצפות מקוד C  למשל (הוזכרו בעניין זה דברי לינוס טרוולדס בגנות C++, וג'ואל ספולסקי – Leaky abstraction). לשם המחשה הסתכלנו על עקרון ה-Inheritance אשר מתכנתים רבים "נופלים בפח" של ייצור אובייקט בסיס ואובייקטים שיורשים ממנו המרחיבים את תכונותיו עד כדי הוספת מתודות שאינן קשורות אליו כלל, מהלך שמוביל לשימושיות מוגבלת וסגנון כתיבת קוד שהולך ומסתבך. הוזכר התהליך האיטרטיבי של יצירת מבנה האובייקטים הנכון, אשר משפיע בעצם על מורכבות הפתרון וכמו כן הצורך לעשות refactoring לפתרון.הוזכרו מספר טכניקות המסייעות לקבלת החלטה האם מבנה האובייקטים נכון או לא, לדוגמא: גודל/אורך המתודות, כמות הפרמטרים והרלבנטיות שלהם, מי משתמש בהן (מאותו אובייקט או מאובייקט אחר), צורת וכמות השימוש ב-members, וכו'. דנו בקיום חוקים לבחינת קוד אשר הופכים את תהליך ה-design למשהו טכני, תהליך אשר משתפר עם הזמן והניסיון והופך לאומנות (ההחלטות לא רק טכניות). הזכרנו את הספר Pragmatic Thinking and Learning של Andy Huntהמזכיר נושאים כמו שיפור למידה ועל הצורך של מתלמדים להשתמש בסט חוקים אשר הולך והופך יותר ויותר לאינטואיציה ככל שהם הופכים ליותר מקצוענים. דנו במפגש Code retreat with Corey Haines ועל הדינמיקה והתרגול שהיו במפגש. באותו הקשר דיברנו על נתינת שמות לאובייקטים, התרגול של מחיקת קוד וכתיבתו מחדש, הקשר בין תיעוד ל-refactoring, אי שכפול קוד, שימוש ב-pair programming ועוד.דיברנו על מצב של אובייקט (State), ועל הצורך להימנע משימוש בו, והקושי ליישם אותו נכון באופן שמי שמשתמש באובייקט יעשה זאת נכון וללא טעויות.דיברנו קצת על השילוב בין מתודולוגיית תכנות פונקציונלית לבין מתודולוגיה מונחית עצמים, כמו למשל תכנות מונחה עצמים ב-C# אשר עושה שימוש פונקציונלי ב-Linq. סטטיסטיקות ומספרים:1.      שפות פופולריות ב-2011 – מעניין לראות את החלוקה בין השפות השונות, למרות שיש סתירה מסוימת בין שני האתרים הבאים:a.       http://blog.codeeval.com/the-most-popular-programming-languages-of-201b.      http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html2.      אינטרנט במספרים – 2011a.       http://royal.pingdom.com/2012/01/17/internet-2011-in-numbers/לינקים נוספים:1.      Effect Mapping – טכניקה שמסייעת לתכנן פרויקטי פיתוח תוכנה טוב יותר על ידי הגברת הנראות של התוכנית, התכנון, סדרי העדיפות ומסגרת הפרוייקט תוך התמקדות בדרישות הרלבנטיות בלבד.2.      Overview of the object-oriented paradigm3.      דו"ח הבוחן את השימוש בפרדיגמת פיתוח מונחה עצמים – Has the object oriented paradigm kept its promise? תודה רבה לגל כהן על התקצור והוספת הלינקים המעשירים!  הקובץ נמצא כאן האזנה נעימה