ocp והרחבת שיכבת ה Domain של השואב הרובוטי

זהו השואב הרובוטי שלנו :

אשר חובר באמצעות Wifi למחשב .

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

נניח ששיכבת ה BL של התוכנה במחשב בנויה בצורה הבאה :

במרכזה של שיכבת ה Domain נמצא לו ה CleaningProcessOrchestrator שמכיל לוגיקה של Workflow .על סמך Events שהוא מקבל מ Entities שונים הוא מבצע החלטות ומפעיל Entities אחרים בהתאם .

 

מבחינת Deployment של ה packages המערכת נראתה כך:

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

קודם כל הגיע מכשיר חדש די דומה. ה Sensor יחיד ובודד שודרג אבל הלוגיקה של CleaningProcessOrchestrator נשארה אותו הדבר .

את אותו ה package של ה Domain שיכבת ה BLL פיצלנו 3 package שיכיל את כל המרכיבים המשותפים ועבור כל מכשיר יהיה package יעודי עם הclassים הקונקרטים רק לו.

 

ה packages הקונקרטים נשארו מאוד אנמיים ומכיוון ש CleaningProcessOrchestrator נשאר כמעט אותו הדבר ועל מנת להימנע משכפול קוד הוחלט  להשאיר את ה CleaningProcessOrchestrator ב Base Domain package .

גישה לEntities השונים מתבצעת באמצעות פנייה ל EntitiesRepository אשר מביאה  Entity קונקרטי .

למה לא בחרנו פשוט לרשת מ CleaningProcessOrchestrator ל Class קונקרטי ?

כי לא היה כל הבדל בין הלוגיקות הנדרשות רק ה sensor השתנה .אם היינו יוצרים CleaningProcessOrchestrator יעודי הדבר היה גורר עבודה ולוגיקה נוספת בתוכנית אשר רצינו להימנע ממנה .

אח”כ באה דרישה חדשה לעשות מערכת שדומה מאוד לקודמת למעט תיפקוד מיוחד כאשר צריכם לבא אורחים ויש להאיץ את פעולת השואב.

נפתח את הכל ונשנה ארכיטקטורה ? לא חבל בסך הכל נדרש שינוי מינורי ב CleaningProcessOrcastrator שלנו.

כל שינוי בהמשך הוסף ל CleaningProcessOrchestrator היחיד עוד תנאי בסגנון :

if mCurrentWorkingMode == BeforeGuestsAreComing 
    mBrushesEntities.SetSpeed (MaxSpeed)
end 

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

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

הפתרון של להגדיר את ה  CleaningProcessOrchestrator כ Abstract  ועבור כל תצורה של מערכת לרשת ממנו וליצור class קונקרטי גם יוצר בעיה מימושית עקב העובדה שבתצורות השונות יש הרבה לוגיקה משותפת .

הפתרון שבחרנו הינו להגדיר את הלוגיקה של CleaningProcessOrchestrator בקובץ קונפיגורציה כדוגמא באמצעות spring integration , camel  או WF .

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