שלום חברים בוקר טוב
אנחנו מתקדמים לחלק השלישי מתוך 5 העקרונות של ה SOLID
כל הכבוד למי שמתמיד וממשיך לעקוב, מי שלא הספיק אני מצרף פה לינק לעקרון הקודם …
כמו שראינו חלק מאנשי הDATA משתמשים בפייתון ביום יום
חלקם מבצעים טרנספורמציות בתהליכי הETL
וחלקם בכדי לבצע אוטומציות לפעולות אחרות בתהליך ליצירת DWH וארכיטקטורה אידיאלית לנתונים שמגיעים ממקורות שונים.
היום נמשיך ללמוד על עקרונות הSOLID ונגיע לחלק השלישי שיעזור לקוד שלנו להיות מודולרי
SOLID זה בעצם ראשי תיבות באנגלית של :
חמשת העקרונות האלו פורסמו לראשונה על ידי מהנדס התכנה האמריקאי רוברט סי. מרטין בתחילת שנות האלפיים, והמחשבה מאחורי העקרונות היא שכאשר הם מיושמים יחדיו בפיתוח של מערכת תכנה, סביר שהיא תהיה יותר קלה לתחזוק והרחבה לאורך הזמן.
חלק מהסיבות שאנו צריכים לממש את העקרונות האלו ולהקפיד עלייהם הוא שאנו רוצים יכולת להוסיף תכונות לקוד שלנו בצורה מהירה בעתיד וגם שקוד ירוץ מהר תמיד ולא תמיד אפשר להשיג הכל (זמן, פיצרים, משאבים) אלא אם כן מיישמים עקרונות חשובים אלו כבר מההתחלה של התכנון.
אוקי נתחיל:
האות השלישית היא L
שמסמלת את העקרון הראשון שהוא Liskov Substitution Principle | LSP
העיקרון הוצג לראשונה על ידי מדענית לתחום מדעי המחשב בשם ברברה ליסקוב.
“אובייקטים בתוכנה יכולים להיות מוחלפים על ידי מחלקות יורשות ללא שינוי תפקוד התוכנה בכללותה”
זו ההגדרה היבשה, אבל מה זה אומר בפרקטיקה?
שימו לב העקרון הזה הוא אחד הבסיסיים ביותר בעולם תכנות מונחה עצמים ובכל זאת, גם מפתחים מנוסים חורגים ממנו לפעמים בלי לשים לב. העקרון הוא פשוט: כל טיפוס (מחלקה) שיורש מטיפוס אחר, חייב להיות חליפי לו, כך שאם מחלקה B יורשת את מחלקה ,Aאז בכל מקום בקוד שבו מצפים לאובייקט מסוג A נוכל לספק אובייקט מסוג B ללא כל שינוי בהתנהגות.
בעצם – מופע של מחלקת בן תמיד יוכל להחליף מופע של מחלקת האב והמשתמש אינו ירגיש בכך.
[מבלבל ? ברור… תכף נראה דוגמה שתעשה לנו סדר 😊 ]
העיקרון הזה מבטיח שימוש נכון בירושה (אחד מעקרונות ה-OOP).
=============================================================
בואו נציג דוגמה של תוכנית שמיישמת את העקרון
בואו נניח שיש לנו מחלקה ראשית שנקראת Shape עם 4 מתודות ושלוש מחלקות שונות, שיורשות את המחלקה הראשית. על פי העקרון אנו אמורים להיות מסוגלים להפעיל מתודה של המחלקה הראשית בלי לדעת בכלל איזו מחלקה יישמה בפועל את המתודה
הנה קטע קוד שימחיש את העניין
יש לנו מחלקה ראשית של צורה שבשביל להחיל אותה על צורה צריך לציין את שם הצורה
עם 2 מתודות ריקות לחישוב שטח והיקף,
בנוסף 3 מחלקות שונות למלבן, ריבוע, ועיגול שבהן המתודות כתובות כראוי ומלאות בחישוב מתמטי לצורך החזרת ערך למשתמש.
מלבן צריך לקבל פרמטרים של גובה ורוחב
ריבוע את האורך של צלע אחת (מספיק)
ועיגול נקבל את הרדיוס
ובסוף אני מריץ את המתודות על כל הצורות כולן (מתוך רשימה)
עכשיו החלק המעניין
הפונקציה print_shape_info לא יודעת מי המחלקה שהפעילה את המתודה של החישוב, היא פשוט מכירה את המחלקה Shape הראשית. ובהתאם לעקרון ההחלפה של Liskov אנחנו יכולים לגשת למתודות של Shape בכל הנמחלקות היורשות ממנה.
=============================================================
לכן, כאשר אתה מרחיב מחלקה, אם חלק מהמאפיינים של המחלקה הראשית לא שימושיים עבור המחלקה החדשה, עקרון ההחלפה של Liskov יופר.
והפתרון לכך פשוט: ניצור ממשקים התואמים את צרכי המחלקה היורשת.
לסיכום, אם מחלקה יורשת מחלקה אחרת, עליה לעשות זאת באופן שכל המתודות של המחלקה ה”מורשת” יישארו רלוונטיים לפונקציונליות שלה.
נתראה בפעם הבאה על העיקרון ה4 על קצה המזלג 😊
מקווה שנתתי ערך.
Komentáře