יום חמישי, 9 בפברואר 2012

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++, וג'ואל ספולסקי – 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 – מעניין לראות את החלוקה בין השפות השונות, למרות שיש סתירה מסוימת בין שני האתרים הבאים:
2.      אינטרנט במספרים – 2011
לינקים נוספים:
1.      Effect Mapping – טכניקה שמסייעת לתכנן פרויקטי פיתוח תוכנה טוב יותר על ידי הגברת הנראות של התוכנית, התכנון, סדרי העדיפות ומסגרת הפרוייקט תוך התמקדות בדרישות הרלבנטיות בלבד.
3.      דו"ח הבוחן את השימוש בפרדיגמת פיתוח מונחה עצמים – Has the object oriented paradigm kept its promise?

תודה רבה לגל כהן על התקצור והוספת הלינקים המעשירים! 

הקובץ נמצא כאן האזנה נעימה

3 תגובות:

  1. היי, לא יודע למה אמרתם שגישה ObjectOriented מתאימה יותר לUI, וגישה פונקציונלית מתאימה יותר לBackEnd.

    איך שאני רואה את זה, בעולם הORM הגישה ה-ObjectOriented דווקה מאוד הגיונית בBackEnd.
    ולעומת זאת, בעולם הFatClient שבו משתמשים הרבה בג'אווהסקריפט ואג'קס הגישה הפונקציונלית דווקא ממלאת תפקיד חשוב בUI.

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

    אוהב מאוד את הפודקסט ובמיוחד את Final Class.כן יירבו.

    השבמחק
  2. אבי, אני חושב שמשלושים אלף רגל זה נכון להגיד ש OOP מתאים יותר ל UI (ודרך אגב, לשם כך הוא נבנה במקור) ועבור backend, ותסלח לי על ההכללה הגסה, OOP מתאים במקרים מסויימים אבל קצת פחות ולפעמים הוא overused שלא בצדק. אני חושב שבהרבה מקרים כאלה תכנות פונקציונלי יתאים יותר.
    כמובן שלכל כלל יש יוצא מן הכלל. דווקא לגבי ORM אני חייב להגיד שהדעות מאות חלוקות.

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

    השבמחק