דפים

Thursday, June 16, 2011

תלויות או לא להיות

הפוסט הבא שלי הוא בהשראת המאמר שקראתי לאחרונה ב CodeGuru שעסק בצימצום תלויות בפרוייקט C++ על ידי שימוש ב"תבנית המפעל" (Factory Pattern).

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

תרשים מחלקות שלקחתי מהאתר OODesign, נראה כך:



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

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

כותב המאמר ב CodeGuru צייר את התרשים הבא כדוגמא לתלויות בלתי רצויות בקוד:


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

אחד הפרוייקטים עליהם אני אחראי כעת נכתב על ידי ארבעה אנשים (כולל אותי) במשך כ 3 שנים. עבודה באוירה לוחצת ונלחצת כמו בהייטק מצריכה מאיתנו לעשות ויתורים שונים על מנת לעמוד בלוח הזמנים הלוחץ. כמה פעמים הזנחתם warning של הקומפיילר שלוקח יותר מ 5 דקות לתקן ואמרתם שאין לכם זמן לזה עכשיו? כמה פעמים עשיתם include להדרים שאין לכם צורך בהם ואחרי זה לא יצא לכם למחוק כי הבדיקה מה צריך ומה לא תיקח לכם זמן שאתם צריכים להשקיע בפתרון באגים? גם הקוד שלנו מכיל חטאים כאלה.

מהפכני ככל שזה ישמע, החלטתי לעשות שינוי.

השינוי לא יהיה רוחבי, כי זה קשה מידי, לוקח יותר מידי זמן ולא ריאלי במציאות היומיומית שלי. השינוי יהיה הדרגתי ויתבצע כך: בכל קובץ שאני נוגע במסגרת תיקון, שינוי או כתיבה פיצ'ר חדש אני אדאג להעלים את ה warnings ואת התלויות הלא רצויות, אבדוק אילו includes אפשר להעביר לקובץ המימוש ולהוציא מתוך ה header על ידי שימוש ב forward declarations ואמחק תלויות לא נחוצות שנשכחו במרוצת הזמן. בתקווה להגיע לקוד שמתקמפל מהר יותר ונקי יותר.

מעניין איך קריאת מאמר ב CodeGuru מניעה מהפיכות :)

נסיים כרגיל בשיר בנושא.


No comments:

Post a Comment