תבניות עיצוב ואוטומציה | Factory Pattern



בתור מפתחי אוטומציה (ותוכנה בכלל) אנחנו נתקלים בלא מעט בעיות..

אנחנו לא זוכרים syntax מסוים, נזרק לנו exception שאנחנו רואים פעם ראשונה או אפילו שגיאת קומפילציה שאנחנו לא מכירים.

מה אנחנו עושים כדבר כזה קורה לנו? לרוב נפנה לדר' גוגל... הרי כל דבר שקרה לנו כבר קרה למישהו אחר בעבר, ובכל בעיה בה נתקלנו, אנחנו כנראה לא הראשונים שנתקלנו בה.
ב-95% מהמקרים גוגל אכן פותר לנו את הבעיה.

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

לשם כך נוצרו Design Patterns!
Desing Pattens הן הפתרונות לבעיות שלנו בעיצוב התוכנה - אלו מעין תבניות פתורות וכל מה שנשאר למשתמש זה להתאים אותן למקרה שלו.

במילים אחרות, Design Patterns זה פשוט פתרון לבעיה בעיצוב הקוד.

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


מה זה Factory Pattern?

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

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

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

איך זה מתקשר לאוטומציה?

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

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

דוגמה ל Factory Pattern ב C#

אז כמו שציינתי קודם, בתכנית יהיו לנו מספר מחלקות הממשות interface בשם, IDevice, כל אחת בדרכה שלה.

IDevice יהווה עבורנו חוזה של הפונקציונליות הבסיסית שצריכה להיות למכשיר.
לצורך הדוגמה נכתוב רק פעולה אחת בשם ()OpenApplication.


אז ניצור במחלקה DeviceFactory פעולת Factory אשר תקבל כפרמטר שם יצרן ותנסה ליצור מופע של המחלקה המתאימה ליצרן שקיבלה.


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

כעת, בתכנית הראשית שלנו או בתרחיש הבדיקה שלנו, ניצור עצם של Device באמצעות ה Factory Method שכתבנו ונקרא לפעולה ()OpenApplication.

באותה מידה שהפלט לפונקציה GetDevice הוא Hard Coded ניתן גם לקבל אותו בכל דרך אחרת (קובץ קונפיגורציה, שינוי מה-UI  וכו'..)

והפלט יראה כך

סיכום

היום למדנו על Design Pattern בשם Factory Pattern (או Factory Method).

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

באמצעות Factory Pattern נוכל ליצור עצם במהלך הריצה שלנו בהתבסס על החלטות שנתונות לשיקולנו.

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

עצור לרגע וחשוב היכן בקוד שלך Factory Patten  יוכל להועיל לך.

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


תגובות

  1. פוסט מעולה , פשוט וקל להבנה!
    נהנתי לקרוא.

    השבמחק
  2. כיף לקרוא - פוסט כ"כ מובן !

    השבמחק
  3. פוסט מצוין קצר וברור

    השבמחק
  4. תודה רבה על ההסבר המעולה! לא מובן מאליו על ההשקעה בכתיבה!!

    השבמחק

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

תכנות מונחה עצמים | Dependency Inversion Principle

מהם קבצי DLL ואיך להשתמש בהם?

מה ההבדל בין אוטומציה לפיתוח רגיל