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

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

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

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

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

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

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

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

בהמשך לסדרה שלנו שלנו על תבניות עיצוב ואוטומציה, ה Pattern עליו נדבר היום נקרא Facade.

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

Facade הוא אחד ה Patterns היותר אינטואיטיביים ופשוטים למימוש שיש, ואינו דורש מעבר להבנה בסיסית בתכנות מונחה עצמים.

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

מה זה Facade?

Facade הוא בעצם תבנית עיצוב פשוטה שמטרתה להגדיר interface פשוט שמבצע הרבה פעולות מאחורי הקלעים.

דוגמה פשוטה תהיה משיכת כסף מהכספומט...

אם נגיע לבנק ונבקש מהכספומט משיכה של 200 ש"ח, נוכל לקבל לרוב שני סוגים של תשובות.

הראשונה - המשיכה בוצעה בהצלחה (ונקבל 200 שקלים)

השנייה - אין מספיק כסף בחשבונך

מה שבתור משתמש הקצה איננו רואים זה את כל התהליך שקורה מאחורי הקלעים:

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

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

דוגמה ל Facade ב C#

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

לצורך הדוגמה אציג "מימוש" של הכספומט עליו דיברנו קודם.

שלב 1:

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

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

ניתן לראות שכל מחלקה מממשת interface - זאת על מנת לא לחלל את העקרונות הקדושים של SOLID

שלב 2:
לאחר יצירת המחלקות ניצור מחלקה נוספת לה נקרא ATMFacade.
המחלקה תכיל כשדות את כל שאר המחלקות, ותשתמש בהן באמצעות פעולה בשם WithdrawMoney.



שלב 3:
בעת השימוש שלנו בכספומט (במקרה זה, במחלקה Program) ניצור מופע של ATMFacade ונשמש בפעולה WithdrawMoney כרצוננו.



הערה: אם תהית מדוע אנחנו יוצרים את המחלקות בהן ה facade משתמש מחוץ ל constructor, אנו עושים זאת כדי לא לחלל את העיקרון Dependency Inversion Principle.

וזהו, יש לנו Facade :)

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

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

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

לאחר שהפרדנו ניצור Facade עם הפעולות שיעניין אותנו לבדוק ונקרא לו מתרחיש הבדיקה.

סיכום

היום למדנו Design Pattern בשם Facade, העוזר לנו ביצירת ממשק פשוט למערכת גדולה המכילה בתוכה תתי מערכות.

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

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