דפוס עיצוב גשר

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

מהי תבנית הגשר?

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

Shape.java
```
public abstract class Shape {
   public abstract void draw();
}
```
כשנחליט להוסיף צורות כמו משולשים ומלבנים, נגרום להם לרשת את Shapeהמחלקה:

Rectangle.java:


public class Rectangle extends Shape {
   @Override
   public void draw() {
       System.out.println("Drawing rectangle");
   }
}

Triangle.java:


public class Triangle extends Shape {
   @Override
   public void draw() {
       System.out.println("Drawing triangle");
   }
}

הכל נראה פשוט עד לרגע בו אנו מציגים את מושג הצבע. כלומר, לכל צורה יהיה צבע משלה, והפונקציונליות של draw()השיטה תהיה תלויה בצבע זה. כדי לקבל יישומים שונים של draw()השיטה, אז עלינו ליצור מחלקה עבור כל שילוב צורה-צבע. אם יש לנו שלושה צבעים, אז אנחנו צריכים שש מחלקות: TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack, RectangleGreenו RectangleRed. שישה שיעורים זה לא בעיה כל כך גדולה. אבל! אם אנחנו צריכים להוסיף צורה או צבע חדשים, אז מספר המחלקות גדל באופן אקספוננציאלי. איך לצאת מהמצב הזה? אחסון צבע בשדה וספירת כל האפשרויות באמצעות הצהרות מותנות אינו הפתרון הטוב ביותר. פתרון טוב הוא להעביר צבע לממשק נפרד . לא מוקדם יותר מאשר נעשה: בואו ניצור Colorממשק עם שלושה יישומים: BlackColor, GreenColorו RedColor:

Color.java:


public interface Color {
   void fillColor();
}

BlackColor.java:


public class BlackColor implements Color {
   @Override
   public void fillColor() {
       System.out.println("Filling in black color");
   }
}

GreenColor.java


public class GreenColor implements Color {
   @Override
   public void fillColor() {
       System.out.println("Filling in green color");
   }
}

RedColor.java


public class RedColor implements Color {
   @Override
   public void fillColor() {
       System.out.println("Filling in red color");
   }
}

כעת נוסיף Colorשדה לכיתה Shape. נקבל את הערך שלו בקונסטרוקטור.

Shape.java:


public abstract class Shape {
   protected Color color;
  
   public Shape(Color color) {
       this.color = color;
   }

   public abstract void draw();
}

נשתמש colorבמשתנה Shapeביישום. המשמעות היא שצורות יכולות כעת להשתמש בפונקציונליות של Colorהממשק.

Rectangle.java


public class Rectangle extends Shape {

   public Rectangle(Color color) {
       super(color);
   }

   @Override
   public void draw() {
       System.out.println("Drawing rectangle");
       color.fillColor();
   }
}

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

איך בונים גשר: הפשטה ויישום

הבה נסתכל על דיאגרמת מחלקה המתארת את תבנית הגשר: היכרות עם דפוס עיצוב הגשר - 2

כאן ניתן לראות שני מבנים עצמאיים שניתן לשנות מבלי להשפיע זה על הפונקציונליות של זה. במקרה שלנו:

הפשטה היא Shapeהכיתה
RefinedAbstraction הוא ה- Triangleand Rectangleclasses
מיישם הוא Colorהממשק
ConcreteImplementor הוא ה- BlackColor, GreenColorו- RedColorclasses.

המחלקה Shapeהיא הפשטה - מנגנון לניהול מילוי של צורות בצבעים שונים, אשר מעביר לממשק Color(Implementor). המחלקות Triangleוהן Rectangleהן כיתות קונקרטיות המשתמשות במנגנון שהמעמד זמין Shape. BlackColor, GreenColorוהם RedColorיישומים קונקרטיים בהיררכיית היישום.

היכן להשתמש בתבנית הגשר

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

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

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

יתרונות וחסרונות של הדפוס

כמו דפוסים אחרים, לגשר יש גם יתרונות וגם חסרונות. יתרונות דפוס הגשר:

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

החסרונות של תבנית הגשר:

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

הבדל מדפוס האסטרטגיה

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