דפוס המתווך בג'אווה

1. סקירה כללית

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

כרגיל, נספק דוגמת קוד פשוטה.

2. תבנית מגשר

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

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

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

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

3. דיאגרמת ה- UML של תבנית המגשר

בואו נסתכל על התבנית באופן חזותי:

בתרשים ה- UML לעיל נוכל לזהות את המשתתפים הבאים:

  • מתווך מגדיר את הממשק עמית אובייקטים משתמשים כדי לתקשר
  • עמית מגדיר את המעמד המופשט המחזיק בהתייחסות יחידה ל- מתווך
  • ConcreteMediator מקפל את לוגיקת האינטראקציה בין עמית חפצים
  • בטון קולגה 1 ו בטון קולגה 2 לתקשר רק דרך מתווך

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

כתוצאה מכך, בטון קולגה 1 ו בטון קולגה 2 ניתן לעשות בהם שימוש קל יותר.

כמו כן, למקרה שנצטרך לשנות את הדרך עמית אובייקטים עובדים יחד, אנחנו רק צריכים לתקן את ConcreteMediator הִגָיוֹן. או שנוכל ליצור יישום חדש של ה- מתווך.

4. יישום ג'אווה

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

4.1. תרחיש לדוגמא

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

בואו נסתכל על יישום הדוגמה:

כיתת ציבור כפתור {אוהד אוהדים פרטי; // קונסטרוקטור, גטרים וקובעים לחץ בטל פומבי () {if (fan.isOn ()) {fan.turnOff (); } אחר {fan.turnOn (); }}}
מאוורר בכיתה ציבורית {כפתור כפתור פרטי; ספק כוח ספק פרטי; בוליאני פרטי isOn = false; // קונסטרוקטור, גטרים וקובעים public public turnOn () {powerSupplier.turnOn (); isOn = נכון; } בטל ציבורי בטל () {isOn = false; powerSupplier.turnOff (); }}
מחלקה ציבורית PowerSupplier {public void turnOn () {// יישום} public void turnOff () {// יישום}}

לאחר מכן, בואו נבדוק את הפונקציונליות:

@ מבט בטל ציבורי givenTurnedOffFan_whenPressingButtonTwice_fanShouldTurnOnAndOff () {assertFalse (fan.isOn ()); כפתור. לחץ (); assertTrue (fan.isOn ()); כפתור. לחץ (); assertFalse (fan.isOn ()); }

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

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

4.2. הוספת תבנית המגשר

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

ראשית, בואו נציג את מתווך מעמד:

מגשר ציבורי ציבורי {לחצן כפתור פרטי; אוהד מאוורר פרטי; ספק כוח ספק פרטי; // קונסטרוקטור, גטרים וקובעים לחץ בטל בפומבי () {if (fan.isOn ()) {fan.turnOff (); } אחר {fan.turnOn (); }} התחלה בטלנית ציבורית () {powerSupplier.turnOn (); } עצירה בטלנית ציבורית () {powerSupplier.turnOff (); }}

לאחר מכן, בואו לשנות את השיעורים הנותרים:

כיתת כיתת ציבור {מגשר מגשר פרטי; // בונה, גטרים וקובעים עיתונות בטל פומבית () {mediator.press (); }}
אוהד ממעמד ציבורי {מגשר מגשר פרטי; בוליאני פרטי isOn = false; // בונה, גטרים וקובעים פומבי ריק TurnOn () {mediator.start (); isOn = נכון; } בטל ציבורי בטל () {isOn = false; mediator.stop (); }}

שוב, בואו נבדוק את הפונקציונליות:

@ מבט בטל פומבי givenTurnedOffFan_whenPressingButtonTwice_fanShouldTurnOnAndOff () {assertFalse (fan.isOn ()); כפתור. לחץ (); assertTrue (fan.isOn ()); כפתור. לחץ (); assertFalse (fan.isOn ()); }

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

כעת, לאחר שהטמענו את דפוס המתווך, אף אחד מ- לַחְצָן, אוהד, או ספק כוח שיעורים מתקשרים ישירות. יש להם רק התייחסות יחידה ל מתווך.

אם נצטרך להוסיף ספק כוח שני בעתיד, כל שעלינו לעשות הוא לעדכן מגשר הִגָיוֹן; לַחְצָן ו אוהד השיעורים נותרים ללא מגע.

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

5. מתי להשתמש בתבנית המתווך

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

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

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

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

6. מסקנה

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

כמו תמיד, דוגמאות הקוד המלאות זמינות ב- GitHub.


$config[zx-auto] not found$config[zx-overlay] not found