תבנית עיצוב

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

בהנדסת תוכנה, תבנית עיצובאנגלית: Design pattern) היא פתרון כללי לבעיה שכיחה בעיצוב תוכנה. תבנית עיצוב אינה עיצוב סופי שניתן להעבירו הישר לקוד, אלא תיאור או תבנית לדרך לפתרון בעיה, שעשויה להיות שימושית במצבים רבים. תבניות עיצוב מונחות עצמים מציגות לרוב יחסים וקשרי גומלין בין מחלקות או אובייקטים, בלי לפרט את המחלקות או אובייקטי היישום הסופיים המעורבים. אלגוריתמים אינם נחשבים כתבנית עיצוב, כיוון שהם פותרים בעיות חישוביות ולא בעיות עיצוב.‏[1]

עקרונות מאחורי תבניות עיצוב[עריכת קוד מקור | עריכה]

ברוב תבניות העיצוב נעשה שימוש במספר רעיונות: OCP - Open Closed Principle (עיקרון הפתיחות להרחבה והסגירות לשינויים), ו- ISP - Interface Segregation Principle (עיקרון הפרדת הממשקים).

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

בהיבט רחב יותר ניתן למצוא שילובים של תבניות עיצוב היכולים להיחשב כתבניות ארכיטקטורה משום שהם משפיעים על ההיבט הארכיטקטוני של התוכנה הנכתבת מעבר לסוגיית עיצוב תוכנה מקומית.‏[2] דוגמה לשילוב נודע מסוג זה היא תבנית ה-Model-View-Controller.

היסטוריה[עריכת קוד מקור | עריכה]

מקורם של תבניות העיצוב הוא מתחום הארכיטקטורה, בשנת 1977, כריסטופר אלכסנדר, ארכיטקט במקצועו, הוציא ספר‏[3] ובו הגדיר באופן פורמלי 253 בעיות מוכרות מעולם האכיטקטורה ולהן פתרונות אבסטרקטים. עשר שנים מאוחר יותר ב-1987 קנט בק ווורד קנינגהם השתעשעו ברעיון של השמה של תבניות עיצוב לעולם התכנות, הם הציגו את תוצאותיהם בוועידת OOPSLA. בנוסף הם עיצבו יחד תבנית עיצוב לעיבוד קרניים גרפיות בשפת Smalltalk.

  • בשנת 1988 אריך גמא התחיל לכתוב עבודת מחקר לדוקטורט באונברסיטת ציריך בנושא "קווים כלליים לעיבוד תוכנה".
  • בשנת 1991 לאחר עבודת מחקר שארכה כשנתיים הוציא ג'יימס קופלין ספר בשם "Advanced C++ Idioms" - המכיל מגוון דוגמאות לפתרון בעיות שונות בתכנות ב C++.


כנופיית הארבעה או Gang of Four[עריכת קוד מקור | עריכה]

כינוי שניתן לאריך גמא, ריצ'רד הלם, רלף ג'ונסון וג'ון ויליסידס, מחברי הספר: Design Patterns - Elements of Reusable Object-Oriented Software. (שמם שאול מכנופיית הארבעה הסינית). ספרם שיצא ב-1994 היה הראשון שאסף ותיעד באופן מעמיק תבניות עיצוב. עשרים ושתיים תבניות העיצוב שהופיעו בספר הפכו עם השנים לתבניות העיצוב המוכרות ביותר והיוו בסיס לכל ידע נוסף שנצבר בתחום תבניות העיצוב.

בין התבניות העיקריות שתועדו:

תיעוד[עריכת קוד מקור | עריכה]

דוגמה של תרשים UML של מחלקה המממשת את תבנית Singleton

הגדרת תבנית עיצוב תכיל את הפרמטרים הבאים:

  • שם תבנית העיצוב וסיווגה
  • תיאור אבסטרקטי של הבעיה אותה תבנית העיצוב נועדה לפתור
  • הצגת הפתרון בצורה מורחבת הכוללת תרשים OMT‏ (Object Modeling Technique) או UML‏ (Unified Modeling Language).
  • תוצאות והשלכות של יישום הפתרון המוצע

דוגמה[עריכת קוד מקור | עריכה]

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

יתרונות[עריכת קוד מקור | עריכה]

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

התנגדות[עריכת קוד מקור | עריכה]

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

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

במהלך ההתפתחות של תבניות העיצוב הוגדרו גם תבניות אשר מציעות כביכול פתרון לבעיה מסוימת, אך הפתרון המוצע הוא רע, ואינו מציג דרך נכונה להתמודדות עם הבעיה. תבניות אלו נקראות Anti Pattern. יש הטוענים שגם בין תבניות העיצוב המקובלות כמומלצות קיימות תבניות שאינן מספקות פתרון טוב לבעיה ומהוות Anti Pattern. דוגמה לתבנית כזאת היא התבנית Singleton אשר מצד אחד מקובלת על מתכנתים רבים כאחת התבניות הטובות ביותר ולדעת אחרים היא Anti Pattern. דעות סותרות אלו מראות שהסתמכות בעיינים עצומות על תבניות מוגדרות מוטעית מיסודה ויכולה לגרום לטעויות שתעלנה ביוקר הן מבחינת זמן והן מבחינת משאבים ותקציב. ‏[4]

תבניות עיצוב נפוצות[עריכת קוד מקור | עריכה]

ניתן לחלק את התבניות בגדול לשלושה סוגים:‏[5]

תבניות יצירה[עריכת קוד מקור | עריכה]

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

שם התבנית תיאור UML
תבנית Abstract Factory "בית חרושת ליצירת אובייקטים" - ממשק המשמש ליצירת אובייקטים תלויים, ללא ציון המחלקות הנוצרות.

נשתמש כאשר:

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

נשתמש כאשר:

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

נשתמש כאשר:

  • האלגוריתם ליצירת אובייקטים מורכבים צריך להיות בלתי תלוי בחלקים היוצרים את האובייקט ובהרכבתם.
  • תהליך הבנייה חייב לאפשר ייצוגים שונים עבור האובייקטים הנבנים.
Builder
תבנית Lazy initialization "איתחול עצל" - טקטיקה המאפשרת שליטה על ביזבוז משאבים, חישוב הזמן המתאים ליצירת האובייקט בפועל רק לזמן שחייבים אותו, תוך התחשבות בתהליכים השונים והכרעה איזה תהליך "יקר" יותר.
תבנית Object pool שחרור משאבים על ידי מחזור אובייקטים שאינם בשימוש.
תבנית Prototype הגדרת אבטיפוס של אובייקטים ויצירת אובייקטים חדשים כהעתק שלו.

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

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

נשתמש כאשר:

  • חייב להיות מופע אחד בדיוק של מחלקה, וחייבת להיות נקודת ממשק ידועה למחלקה זו.
  • המופע היחיד יורחב על ידי ירושה, והלקוחות יוכלו להשתמש במופע המורחב מבלי לשנות את הקוד.
Singleton
תבנית Multiton יצירת מצב בו במחלקה יש רק מופעים בעלי שם (לא מצביעים), וסיפוק נקודת גישה גלובלית אליהם. Multiton
תבנית Resource acquisition is initialization הבטחת תוחלת חיים נכונה של אובייקטים, לשם ניהול מושכל של המשאבים.

תבניות מבנה[עריכת קוד מקור | עריכה]

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

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

נשתמש כאשר:

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

נשתמש כאשר:

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

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

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

נשתמש כאשר:

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

נשתמש כאשר:

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

יעילותו של Flyweight תלויה באיך ומתי משתמשים בה. נכון להשתמש בתבנית כאשר כל התנאים הבאים מתקיימים:

  • האפליקציה משתמשת בכמות גדולה של אובייקטים.
  • עלות האכסון גבוהה עקב עלייה בכמות האובייקטים.
  • ניתן להוציא את ה-state של רוב האובייקטים.
  • ניתן להחליף קבוצות רבות של אובייקטים בכמות קטנה יחסית של אובייקטים משותפים, ברגע שמסירים את ה-state החיצוני.
  • האפליקציה של תלויה בזהות האובייקט. בגלל השימוש באובייקטים משותפים, בדיקת זהות תחזיר true עבור אובייקטים שונים.
Flyweight
Proxy מאפשר לשלוט בגישה לאובייקט אחר.

מתאים לשימוש כאשר במקום מצביע רגיל יש צורך במצביע רב תכליתי או מתוחכם לאובייקט. קיימות כמה Proxy סיטואציות בהן נכון להשתמש בתבנית:

  • פרוקסי מרוחק (Remote proxy): מתן ייצוג מקומי עבור אובייקט במרחב כתובות אחר.
  • פרוקסי ווירטואלי(Virtual proxy): יוצר אובייקטים "יקרים" על פי דרישה.
  • פרוקסי מגן (Protection proxy): שולט בגישה לאובייקט המקורי. נוח כאשר רוצים לשלוט בהרשאות שונות לאותו אובייקט.
Proxy

תבניות התנהגות[עריכת קוד מקור | עריכה]

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

שם התבנית תיאור UML
Chain of responsibility מניעת קשר בין השולח של בקשה למקבל שלה על ידי כך שיותר מאובייקט אחד יוכל לטפל בבקשה. שרשור האובייקטים המקבלים והעברת הבקשה לאורך השרשרת עד שאובייקט מטפל בה.

נשתמש כאשר:

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

Chain of Responsibility

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

נשתמש כאשר:

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

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

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

Interpreter

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

נשתמש כאשר:

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

iterator

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

נשתמש כאשר:

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

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

Memento Pattern
Null Object משמש כברירת מחדל לאובייקט, ובכך מונע את הצורך לוודא שהאובייקט אינו null לפני שימוש בו.

Pattern: Null object

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

נשתמש כאשר:

  • כאשר לאבסטרקציה יש 2 היבטים, האחד תלוי בשני. שמירת ההיבטים באובייקטים שונים מסייעת בשינוי ושימוש חוזר.
  • שינוי של אובייקט אחד גורר שינוי באובייקט אחר, ולא ידוע מראש כמה אובייקטים יש לשנות.
  • אובייקט צריך להודיע לאובייקטים אחרים מבלי להניח הנחות לגבי מה הם אותם אובייקטים, כלומר רוצים למנוע צימוד חזק.
A UML diagram of the observer pattern
Blackboard Observer כללי המאפשר מספר קוראים וכותבים. המידע משותף לרוחב המערכת.
State מאפשר לאובייקט לשנות את התנהגות כאשר מצבו הפנימי משתנה. האובייקט ישנה את המחלקה שבה הוא משתמש.

נשתמש כאשר:

  • התנהגות האובייקט תלויה במצבו, והוא חייב לשנותה בזמן ריצה (בתלות במצבו הפנימי).
  • לפעולות יש תנאים גדולים, התלויים במצבו הפנימי של האובייקט. המצב מיוצג, לרוב, על ידי מונים קבועים.
UML Class Diagram of the State Design Pattern
Strategy מגדיר משפחה של אלגוריתמים, מכמס כל אחד מהם, ומאפשר להחליף את השימוש בהם. ניתן לשנות את האלגוריתם באופן עצמאי בלי תלות במשתמשים במחלקה.

נשתמש כאשר:

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

Strategy Pattern in UML Structure

Specification צירוף לוגיקה עסקית בצורה בוליאנית (לא, או, וגם).

English: Specification Design Pattern - UML diagram

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

נשתמש כאשר:

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

Template method UML Class Diagram

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

נשתמש כאשר:

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

Visitor design pattern in the LePUS3 Design Description Language

התבנית Inversion of control אשר מאפשרת הזרקה של אובייקטים מתאימים בשלב ההרצה משמשת כתבנית הבסיסית למערכת התשתית הנפוצה Spring.

קישורים חיצוניים[עריכת קוד מקור | עריכה]

ויקישיתוף מדיה וקבצים בנושא תבנית עיצוב בוויקישיתוף
  • Inversion of Control
  • ד"ר מרק טרכטרוט, [1],סמינר בהנדסת תוכנה - שלמה ארצי
  • דב זילברמן, Design Patterns, הסדרה "תבניות" וסרטונים נוספים

הערות שוליים[עריכת קוד מקור | עריכה]

  1. ^ תבניות עיצוב למתחילים (Design patterns for dummies), ספר מאת ברברה פורצ'ייס, סטיבן הולצ'נר
  2. ^ ספר מאת ראלף ג'ונסון, אריק גאמה וריצ'רד הלם, Design Patterns: Elements of Reusable Object-Oriented Software
  3. ^ A Pattern Language: Towns, Buildings, Construction, by Christopher Alexander
  4. ^ Patterns versus antipatterns
  5. ^ מדריך לתבניות עיצוב וסוגן