תכנות מונחה עצמים | Single Responsibilty 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

לא, אל תצפה להבין מראשי התיבות מה כל עיקרון אומר, ראשי התיבות ושמות כאן אך ורק כדאי להזכיר לנו אילו עקרונות קיימים.

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

עקרון האחריות הבודדת - Single Responsibility Principle

עקרון האחריות הבודדת אומר: לכל מחלקה ומתודה צריכה להיות רק אחריות אחת.

במילים אחרות, צריכה להיות סיבה אחת בודדת שנרצה לבוא ולשנות את הכתוב במחלקה.

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

דוגמה ב-C# על SRP

נגיד ולצורך העניין, התקבלה דרישה עבורנו ליצור "תשתית" אוטומציה עבור מכשיר סלולרי.

התשתית יודעת לבצע התקנת אפליקציה ולכתוב ללוג כשנצטרך.

הקוד שנכתב יראה כך:

נסה לראות אם אתה מצליח להבין מה הבעיה בקוד הכתוב..

הבנת נכון!

המחלקה Device לוקחת על עצמה שתי אחריויות. גם את האחריות של ביצוע הפעולות על המכשיר, וגם את האחריות הכתיבה לLog.

במקום לשלב אותם יחדיו נעדיף תמיד להפריד בניהם לשתי מחלקות נפרדות.

המחלקה Device תראה כך:

המחלקה Logger תראה כך:
כעת, כאשר נרצה לבצע שינוי באופן כתיבת הלוג (כתיבתו לקובץ Excel במקום לקובץ Text לדוגמה) נדע בדיוק לאן אנחנו צריכים ללכת על מנת לבצע את השינוי.

Shivprasad koirala הגדיר את זה יפה: אם לא היינו מפרידים בין המחלקות והיינו צריכים לשנות את אופן הכתיבה ללוג, זה היה כמו - "לדעת שיש לג'ון בעיה וללכת לתקן את בוב".

סיכום

זה היה העיקרון הראשון מבין ה-5.

אני קורא לך לגשת לקוד שלכם ולראות היכן אתה יכולים להפריד את הלוגיקה לפעולות ומחלקות נפרדות.

ההפרדה תהפוך את הקוד לקריא יותר, מובן יותר ונוח יותר לתחזוקה ושיפורים.

נתראה בפוסט הבא :)