10 עקרונות תכנות מונחה עצמים שכל מפתח צריך לדעת

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

אנו מזכירים: לכל קוראי Habr - הנחה של 10 רובל בעת הרשמה לכל קורס Skillbox באמצעות קוד הקידום של Habr.

Skillbox ממליצה: קורס חינוכי מקוון "מפתח ג'אווה".

יבש (אל תחזור על עצמך)

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

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

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

אוסף שינויים

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

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

עקרון פתוח/סגור

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

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

הנה דוגמה לקוד שמפר את העיקרון הזה.

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

אגב, פתיחות-סגירה היא אחד העקרונות של SOLID.

עיקרון אחריות יחידה (SRP)

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

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

עקרון היפוך תלות (DIP)

למעלה היא דוגמה לקוד שבה AppManager תלוי ב-EventLogWriter, אשר בתורו קשור באופן הדוק עם AppManager. אם אתה צריך דרך אחרת להציג הודעה, בין אם זה פוש, SMS או דוא"ל, אתה צריך לשנות את מחלקת AppManager.

ניתן לפתור את הבעיה באמצעות DIP. לכן, במקום AppManager, אנו מבקשים EventLogWriter, אשר יוזן באמצעות המסגרת.

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

הרכב במקום ירושה

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

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

אפילו אפקטיבי ג'אווה מאת ג'ושוע בלוך מייעץ בבחירת הרכב על פני ירושה.

עיקרון החלפה של ברברה ליסקוב (LSP)

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

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

הנה קטע קוד שסותר את LSP.

שיטת השטח (מלבן r) מחשבת את השטח של מלבן. התוכנית תתרסק לאחר הפעלת Square כי Square הוא לא מלבן כאן. על פי עקרון ה-LSP, פונקציות המשתמשות בהפניות למחלקות בסיס צריכות להיות מסוגלות להשתמש באובייקטים של מחלקות נגזרות ללא הוראות נוספות.

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

עיקרון פיצול ממשק (ISP)

עקרון מוצק נוסף. לפיה, אין ליישם ממשק שלא נעשה בו שימוש. שמירה על עיקרון זה עוזרת למערכת להישאר גמישה ומתאימה ל-refactoring כאשר מתבצעים שינויים בלוגיקת ההפעלה.

לרוב, מצב זה מתרחש כאשר הממשק מכיל מספר פונקציות בו-זמנית, והלקוח זקוק רק לאחת מהן.

מכיוון שכתיבת ממשק היא משימה קשה, לשנות אותו לאחר השלמת העבודה מבלי לשבור דבר יהיה אתגר.

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

תכנות עבור הממשק, לא היישום

הכל כאן ברור מהכותרת. יישום עיקרון זה מוביל ליצירת קוד גמיש שיכול לעבוד עם כל יישום חדש של הממשק.

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

זה:

List numbers= getNumbers();

אבל לא:

ArrayList numbers = getNumbers();

הנה יישום מעשי של מה שנדון לעיל.

עקרון האצלה

דוגמה נפוצה היא שיטות equals() ו-hashCode() ב-Java. כאשר יש צורך להשוות בין שני אובייקטים, פעולה זו מואצלת למחלקה המקבילה במקום ללקוח.

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

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

Skillbox ממליצה:

• קורס מעשי "Mobile Developer PRO".
• קורס מקוון יישומי "מנתח נתונים בפייתון".
• קורס מעשי שנתיים "אני מפתח אתרים PRO".

מקור: www.habr.com