תכנות מונחה עצמים | Interface Segregation Principle
על מנת שהמערכות, היישומים והתשתיות שאנחנו מפתחים יהיו חזקים, יציבים וניתנים לתחזוקה ולשינויים, עלינו לדעת כיצד לעצב אותם בצורה הטובה ביותר.
העקרונות הבסיסיים של תכנות מונחה עצמים לרוב אינם יספיקו למפתח בכדי לכתוב מערכת ברמה גבוהה.
היום אני הולך להציג את עקרונות העיצוב SOLID. אלו הם 5 העקרונות הראשונים והחשובים ביותר בעיני של עיצוב תוכנה וקוד באמצעות תכנות מונחה עצמים.
המדריכים וההסברים נכתבו בC#, אך הם מתאימים למתכנתים בכל שפה משום שהכוונה כאן היא להציג עקרונות. לאחר שהבנו את העקרונות ניתן לממשם בכל שפת OOP.
תנאי קדם למדריך: היכרות עם תכנות מונחה עצמים.
מה זה SOLID?
S - single responsibility principle - SRP
O - open closed principle - OCP
L - Liskov substitution principle - LSP
I - interface segregation principle - ISP
D - Dependency injection principle - DIP
לא, אל תצפה להבין מראשי התיבות מה כל עיקרון אומר, ראשי התיבות ושמות כאן אך ורק כדאי להזכיר לנו אילו עקרונות קיימים.
בפוסטים הקרובים אסקור כל אחד מחמשת העקרונות הללו, אצלול לעומקו ואציג אותו באמצעות דוגמאות קוד מהחיים האמיתיים.
עקרון הפרדת הממשקים - Interface Segregation Principle
מה ISP אומר?
עצם מסוים לא אמור לכלול תלות ברכיבים שאינם נדרשים לצורך השימוש בו.
במילים אחרות, לא נרצה לחייב את המשתמש במחלקה שלנו לממש רכיבים ויכולות שאינם רלוונטיים אליו ושאינו משתמש בהם.
על כן, נרצה להפריד את יכולות הקוד שלנו לכמה שיותר ממשקים קטנים וספציפיים.
מטרותיו העיקריות של ISP הן:
- לבודד את הקוד שלנו לממשקים מחלקות ויכולות קטנים ככל האפשר
- למנוע אילוץ של אובייקטים לממש יכולות שאינם צריכים.
אין מה לדאוג אם הנושא עדיין לא ברור, מיד אפרט אותו באמצעות דוגמה.
נגיד שלצורך העניין, התקבלנו למשרת חלומותינו בחברת Samsung.
יום בהיר אחד, מגיעה אלינו דרישה לפתח תוכנה לשליטה אוטומטית עבור טלוויזיה.
קלי קלות! ראשית ניצור Interface של טלוויזיה אשר יכיל את היכולות שלה.
ונממש אותו במחלקה שלנו Television
עברה תקופה, ו-Samsung, שלא מפסיקה להפתיע אותנו יצאה בהמצאה חדשה - Very Smart TV!
"הטלוויזיה המאוד חכמה" דומה מאוד לטלוויזיה הרגילה, מלבד העובדה שאין לה שלט. היא נשלטת רק על ידי פקודות קוליות.
אז ניצור מחלקה חדשה ל"טלוויזיה המאוד חכמה" שלנו ונממש את הממשק שיצרנו קודם לכן, ITelevision.
כעת, ניתן לשים לב לחילול מובהק של עקרון הפרדת הממשקים!
המחלקה VerySmartTelevision מממשת פעולות שאיננה צריכה!
אז מה הפתרון?
ממש כמו בהגדרה. נרצה לפרק את הממשק ITelevision לממשקים קטנים וספציפיים יותר.
ניצור ממשק בשם IRemoteController אשר יכיל את הפעולות שמבוצעות על ידי שלט.
ובנוסף ניצור ממשק ITurnOnAndOff שיהיה אחראי על פעולות הכיבוי וההדלקה.
כעת נוכל לממש את הממשקים ITurnOnAndOff ואת IRemoteController במחלקה Television
בעוד שהמחלקה IVerySmartTelevision תצטרך לממש רק את ITurnOnAndOff ולא תצטרך לממש פעולות אחרות שאין לה שימוש בהן.
סיכום
דבר שמומחים בתחום פיתוח התוכנה אומרים (ואני נוטה להסכים עמם): "לכתוב קוד ברור מובן ושמסביר את עצמו (self explanatory) זה חשוב לפחות כמו לכתוב קוד שעובד".
אני בהחלט מאמין שהעקרון שלמדנו היום, יחד עם שאר העקרונות, יגרום לקוד שלנו להיות ברור ולהסביר את עצמו בדרך הטובה ביותר.
זכרו תמיד, אין סיבה לפחד ממספר גדול של Intefaces, הדבר רק יכול להפוך את הקוד שלנו לקריא יותר ונוח לתחזוקה.
נתראה בפוסט הבא :)
אני בהחלט מאמין שהעקרון שלמדנו היום, יחד עם שאר העקרונות, יגרום לקוד שלנו להיות ברור ולהסביר את עצמו בדרך הטובה ביותר.
זכרו תמיד, אין סיבה לפחד ממספר גדול של Intefaces, הדבר רק יכול להפוך את הקוד שלנו לקריא יותר ונוח לתחזוקה.
נתראה בפוסט הבא :)
או שפשוט לא נשתמש בinterface
השבמחקלמה לא להשתמש ב interface?
מחק