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

במסגרת תכנון העל (High Level Design) ביקשתי מאחד המפתחים המוכשרים שלי לדאוג לכך שכל שירות של היישום יהיה מנותק מהשירותים האחרים, והטיפול בו יתבסס על הקצאה בזמן ריצה באמצעות מפעל מחלקות (אוי כמה שזה נשמע רע בעברית, הכוונה כמובן ל- Class Factory).

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

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

המפעל נראה בגדול כך (נניח לצורך הפשטות שלכל שירות יש שם וייצוג גרפי):

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

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

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

לאלוהי המו"פ הפתרונים…