Factory Pattern חלק א

 מדריך למימוש Factory Pattern (חלק א)



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

בפוסט זה נלמד על Factory Pattern, תבנית זו היא אולי תבנית העיצוב הנפוצה ביותר בשפות תכנות מונחות עצמים.
מטרת תבנית זו הינה לאפשר למשתמש לייצר מספר אובייקטים שונים ע”י ממשק אחיד, כך שמאחורי הקלעים מתבצעות הפעולות הנדרשות ליצירת האובייקט, ומצד שני למשתשמש זה נראה כמעין “קופסא שחורה” שיודעת לייצר אובייקט כלשהו לפי בקשתו. 
ניתן למצוא תבנית זו במספר צורות ומימושים שונים. לפעמים ניתן לראות שתבנית זו נקראת Factory Method  או Abstract Factory, אבל בסוף הכל זה same same.

הגדרת התבנית

Factory pattern הינה תבנית עיצוב יצרנית (Creational). תבנית זו מספקת לנו ממשק המאפשר יצור של אובייקטים במחלקת האב, וביחד עם זאת מאפשר למחלקת הבן לשנות את סוג האובייקט בהתאם לאובייקט הרצוי.
עוד רגע זה יהיה מובן…

למה אני צריך את זה?!

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

אז מה אתה מציע לי בעצם?

Factory Pattern מציעה לנו לשנות את דרך יצירת האובייקט. במקום ליצור אותו בצורה ישירה בקוד, נכתוב פונקציה ליצירת אובייקטים, וכל פעם שנצטרך אובייקט חדש נקרא לפונקציה הזו. פונקציה כזו נקראת – factory function. כלומר, לא יהיה בקוד שלנו יצירת אובייקת חדש ע”י האופרטור new באופן ישיר, אלא אנו נקרא למתודה כלשהי, היא תבנה עבורנו את האובייקט הנצרך, ותחזיר לנו אובייקט מוכן לשימוש.

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

מהצד השני קימיים לנו מחלקות המייצגות את האובייקטים הרצויים (iPhone , Android ), מחלקות אלו צריכות לממש interface ייחודי כלשהו, על מנת שנוכל להחזיר אובייקט מסוג קבוע במחלקת האב.

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

מקרים כללים בהם נרצה להתשמש בתבנית זו

כמה קווים כללים למקרים בהם Factory Pattern יכול להיות שימושי עבורנו, ונרצה לממש יצירת אובייקטים בעזרת תבנית זו:
  • כאשר איננו יודעים בזמן כתיבת הקוד איזה אובייקט נרצה ליצור.
  • כאשר נרצה להסתיר מהמשתמש את אופן ייצירת האובייקט – כימוס (encapsulation).
  • כאשר יצירת האובייקט נתונה להחלטת המשתמש בתוכנית.
  • כאשר תהליך יצירת האובייקט מורכב מכמה גורמים (כמו בקבצי קונפיגורציה למשל) ונרצה לפשט אותו למשתמש.
  • ועוד ועוד…
נראה לי שמספיק להיום, בפוסט הבא נדבר יותר תכלס, נרד יותר לפרטי המימוש, ונראה דוגמה שתאיר את הדברים למי שקצת אבד בדרך.
אז אם נראה לכם שקצת הסתבכתם מההפשטה של הפוסט הזה, אל דאגה, בפוסט הבא הכל יסתדר וישב לכם טוב טוב בראש.
יאללה חברים, נפגש!

One Reply to “Factory Pattern חלק א”

  1. תותח! 💪
    כתוב יפה ומוסבר טוב מאוד.
    אולי אתחיל סוף סוף להשתמש ב design pattern 😅

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *