תכנות מונחה עצמים | Dependency Inversion 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 inversion principle - DIP

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

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

עקרון היפוך התלות - Dependency Inversion Principle

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

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

למה שנרצה להפריד תלות בין רכיבי תוכנה?

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

בנוסף, ברגע שיופרדו התלויות בין רכיבים ניתן יהיה לבצע בדיקות יחידה (Unit Tests) עבור כל רכיב בנפרד.

מה העקרון אומר?

1. מודולים מהרמה הגבוהה אינם צריכים להתלות במודולים מהרמה הנמוכה - שניהם צריכים להתלות באבסטרקציות.
2. אבסטרקציות לא אמורות להיות תלויות בפרטים - פרטים צריכים להיות תלויים באבסטרקציות

מיד נגיע לדוגמה ונראה בדיוק על מה מדובר...

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

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

דוגמה בC# על DIP

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

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

עד כה הכל בסדר גמור.

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

המחלקה תקרא SuperWorker ותראה כך.


כעת ניתן לשים לב שעל מנת שהקוד שלנו יתמוך בSuperWorker נצטרך לשנות גם את האובייקט Manager משום שקיימת בניהם תלות.

וכך מחולל עיקרון היפוך התלות.

אז מה עושים?

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


כאשר Manager יעבוד מול הממשק IWorker - כל שינוי שיהיה מאחורי הקלעים יהיה לו שקוף וכאן בעצם תוקל התלות.

סיכום

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

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

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

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