תבנית עיצוב

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

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

עקרונות מאחורי תבניות עיצוב

ברוב תבניות העיצוב נעשה שימוש נרחב בעקרונות תכנות מונחה עצמים ו- SOLID כמו פולימורפיזם ועקרון פתיחות/סגירות.

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

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

היסטוריה

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

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

כנופיית הארבעה או Gang of Four

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

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

• תבנית Singleton
• תבנית Factory Method
• תבנית ProtoType
• תבנית Command
• תבנית Strategy

תיעוד

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

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

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

דוגמה

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

יתרונות

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

התנגדות

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

יש הטוענים ^{[דרוש מקור]} שתבניות מאטות את ההתקדמות של מתכנתים מתחילים כיוון שהם אינם צריכים להשקיע מאמץ בפתרון בעיות סבוכות. הבעיה נוצרת במיוחד במקרים בהם מעתיקים יישום של תבנית ללא לימוד והבנה מעמיקה של הבעיה והפתרון המוצע. מתכנת מקצועי ילמד קודם את התאוריה שמאחורי התבניות ורק לאחר מכן יחליט באופן מושכל באיזו תבנית להשתמש לפתרון הבעיה. זה עשוי למנוע פיתוח של תוכניות גרועות הכתובות ב"עיוורון" מוחלט.

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

תבניות עיצוב נפוצות

באופן כללי, ניתן לחלק את התבניות לשלושה סוגים:

תבניות יצירה

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

שם התבנית	תיאור	UML
Abstract Factory	"בית חרושת ליצירת אובייקטים" - ממשק המשמש ליצירת אובייקטים תלויים, ללא ציון המחלקות הנוצרות. נשתמש כאשר: המערכת צריכה להיות בלתי תלויה באופן בו ממומשים, נוצרים או מיוצגים התוצרים שלה. כאשר רוצים לתת ספריה של נותני שירות, ורוצים לחשוף רק את הממשק שלהם ולא את המימוש. קבוצה של אובייקטים מתוכננים לעבודה יחדיו, ויש לכפות אילוץ זה.
Factory Method	יצירת עצמים ללא הכרה של המחלקות שלהם, ניתן יכולות למחלקות יורשות לדרוס את השיטה שהממשק חושף עם שיטה משלהם, וכך ליצור את הטיפוס שנדרש. נשתמש כאשר: המחלקה לא יכולה לצפות אילו אובייקטים של איזו מחלקה עליה ליצור. המחלקה מעוניינת לתת למחלקות היורשות לקבוע את האובייקטים הנוצרים. מחלקות מאצילות אחריות לאחת מתוך מספר מחלקות יורשות, ויש לרכז את הידע איזו מחלקה יורשת היא האחת עליה הואצלה האחריות.
Builder	הפרדת יצירת האובייקט מייצוגו, באובייקטים מורכבים. כך ניתן להשתמש באותו תהליך יצירה ליצירת אובייקטים שונים. נשתמש כאשר: האלגוריתם ליצירת אובייקטים מורכבים צריך להיות בלתי תלוי בחלקים היוצרים את האובייקט ובהרכבתם. תהליך הבנייה חייב לאפשר ייצוגים שונים עבור האובייקטים הנבנים.
Lazy initialization	"אתחול עצל" - טקטיקה המאפשרת שליטה על בזבוז משאבים, חישוב הזמן המתאים ליצירת האובייקט בפועל רק לזמן שחייבים אותו, תוך התחשבות בתהליכים השונים והכרעה איזה תהליך "יקר" יותר.
Object pool	שחרור משאבים על ידי מחזור אובייקטים שאינם בשימוש.
Prototype	הגדרת אבטיפוס של אובייקטים ויצירת אובייקטים חדשים כהעתק שלו. נשתמש כאשר: המערכת צריכה להיות בלתי תלויה באופן בו פריטים נוצרים, מורכבים ומייצוגים, וגם מתקיים לפחות אחד מהתנאים מהבאים: כאשר המחלקות עבורן צריך ליצור מופע מצוינות בזמן ריצה, לדוגמה על ידי טעינה דינמית. יש למנוע בניית היררכיה של מחלקות Factory המקבילות להיררכיית מחלקות Product. כאשר למופע של מחלקה יש מספר מצומצם מאוד של מצבים. במקרה זה יהיה נוח יותר לשמור מספר אבות טיפוס ולשכפל אותם, במקום ליצור מופע של המחלקה בכל פעם עבור המצב הנדרש.
Singleton	הגדרת נקודת כניסה יחידה לאובייקט לשם הקצאת מופע יחיד של האובייקט בזיכרון. נשתמש כאשר: חייב להיות מופע אחד בדיוק של מחלקה, וחייבת להיות נקודת ממשק ידועה למחלקה זו. המופע היחיד יורחב על ידי ירושה, והלקוחות יוכלו להשתמש במופע המורחב מבלי לשנות את הקוד.
Multiton	יצירת מצב בו במחלקה יש רק מופעים בעלי שם (לא מצביעים), וסיפוק נקודת גישה גלובלית אליהם.
Resource acquisition is initialization	הבטחת תוחלת חיים נכונה של אובייקטים, לשם ניהול מושכל של המשאבים.

תבניות מבנה

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

שם התבנית	תיאור	UML
Adapter	יצירת התאמה בין מחלקה נתונה (או חיצונית) לבין ממשק מצופה על ידי הגדרת מחלקה המשמשת כ"מַתְאֵם". נשתמש כאשר: נרצה להשתמש במחלקה שהממשק שלה לא מתאים לזה הנדרש. נרצה ליצור מחלקות לשימוש חוזר אשר משתפות פעולה עם מחלקות לא שייכות או לא ידועות, אשר לא בהכרח בעלות ממשק מתאים.
Bridge	"גשר" - יצירת חוסר תלות בין ממשק למימוש, על ידי הפרדה מוחלטת ביניהם. נשתמש כאשר: נרצה למנוע קישור קבוע בין ההפשטה למימוש, לדוגמה כאשר רוצים שהמימוש ייקבע בזמן דינמי. ההפשטה וגם המימוש מורחבים על ידי ירושה. נרצה למנוע הידור מחדש של כל המערכת לאחר שינוי במימוש ההפשטה. יש צורך לשתף מימוש בין מספר אובייקטים, ויש להסתיר עובדה זו מהלקוח.
Composite	גיבוש אובייקטים למבנה היררכי של עץ, אפשור התייחסות לאובייקטים כאובייקטים עצמאיים או באופן אחיד לצירוף של אובייקטים. נשתמש כאשר נרצה שהלקוחות יוכלו להתעלם מההבדלים בין הרכבה של אובייקטים לאובייקטים בודדים, ויתייחסו לשניהם באופן אחיד.
Decorator	הוספת אחריויות נוספות לאובייקט באופן דינמי תוך שמירה על אותו הממשק. Decorator משמש כחלופה גמישה לתת מחלקה כדי להרחיב פונקציונליות. נשתמש כאשר: נרצה להוסיף אחריות באופן דינמי ושקוף לאובייקטים מסוימים (בלא להשפיע על אובייקטים אחרים). הרחבה על ידי ירושה היא לא מעשית. לעיתים נדרש מספר רב של הרחבות בלתי תלויות, דבר העלול ליצור "אינפלציה" של ירושות. או לעיתים הגדרות המחלקה חבויות או שאין אפשרות לרשת ממנה.
Facade	מאפשר ממשק אחיד לאוסף של ממשקים בתת-מערכת. Facade מגדיר ממשק ברמה גבוהה יותר המאפשר שימוש קל בתת-מערכת. נשתמש כאשר: נרצה לתת ממשק פשוט לתת מערכת מורכבת. קיימים יחסי תלות רבים בין הלקוחות והמחלקות המממשות. Facade מסייע בהחלשת הצימוד בין הלקוחות ותתי המערכות. כאשר רוצים לעבוד בשכבות בתתי המערכת, כאשר ה-Facade הוא נקודת הכניסה לרמת התת-מערכת. אם תתי המערכות הן בלתי תלויות, ניתן לפשט את התלות בינן על ידי הקפדה על כך שכל התקשורת בינן תעשה דרך ה-Facade בלבד.
Flyweight	שימוש בשיתוף כדי לתמוך במספר אובייקטים כדי לחסוך בזיכרון. יעילותו של Flyweight תלויה באיך ומתי משתמשים בה. נכון להשתמש בתבנית כאשר כל התנאים הבאים מתקיימים: האפליקציה משתמשת בכמות גדולה של אובייקטים. עלות האחסון גבוהה עקב עלייה בכמות האובייקטים. ניתן להוציא את ה-state של רוב האובייקטים. ניתן להחליף קבוצות רבות של אובייקטים בכמות קטנה יחסית של אובייקטים משותפים, ברגע שמסירים את ה-state החיצוני. האפליקציה של תלויה בזהות האובייקט. בגלל השימוש באובייקטים משותפים, בדיקת זהות תחזיר true עבור אובייקטים שונים.
Proxy	מאפשר לשלוט בגישה לאובייקט אחר. מתאים לשימוש כאשר במקום מצביע רגיל יש צורך במצביע רב תכליתי או מתוחכם לאובייקט. קיימות כמה Proxy סיטואציות בהן נכון להשתמש בתבנית: פרוקסי מרוחק (Remote proxy): מתן ייצוג מקומי עבור אובייקט במרחב כתובות אחר. פרוקסי ווירטואלי (Virtual proxy): יוצר אובייקטים "יקרים" על פי דרישה. פרוקסי מגן (Protection proxy): שולט בגישה לאובייקט המקורי. נוח כאשר רוצים לשלוט בהרשאות שונות לאותו אובייקט.

תבניות התנהגות

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

שם התבנית	תיאור	UML
Chain of responsibility	מניעת קשר בין השולח של בקשה למקבל שלה על ידי כך שיותר מאובייקט אחד יוכל לטפל בבקשה. שרשור האובייקטים המקבלים והעברת הבקשה לאורך השרשרת עד שאובייקט מטפל בה. נשתמש כאשר: יותר מאובייקט אחד צריך לטפל בדרישה, והוא איננו ידוע מראש. יש צורך להעביר דרישה לאובייקט, מבלי לציין את שמו במפורש. קבוצת האובייקטים המטפלים בדרישה ניתנת להגדרה באופן דינמי.
Command	כימוס של בקשה כאובייקט, ובצורה זו מאפשרת להעביר למקבלים בקשות שונות, להכניס בקשות לתור או לרשום אותן ללוג, ולתמוך בביטול פעולות. נשתמש כאשר: Command הוא תחליף מונחה עצמים לפונקציות callback. מציין, מכניס לתור ומבצע דרישות בזמנים שונים. ל-Command יכולת לחיות באופן בלתי תלוי בדרישה המקורית. אם ניתן לייצג את מקבל הדרישה באופן בלתי תלוי במרחב הכתובות, אזי ניתן להעביר את ה-Command לתהליך אחר.
Interpreter	בהינתן שפה, מגדיר ייצוג של הדקדוק שלה יחד עם מפרש שמשתמש בייצוג כדי לפרש את המשפטים של השפה. כאשר יש שפה לפענח, וניתן לייצג את השפה כעצי תחביר מופשטים (לדוגמה ביטוי רגולרי). התבנית תעבוד כאשר: התחביר פשוט. עבור תחביר מורכב נקבל היררכיה גדולה וקשה לניהול. יעילות איננה גורם קריטי.
Iterator	דרך לגשת ברצף לאלמנטים באובייקט המורכב מאוסף של אלמנטים בלי לחשוף את המבנה הפנימי שלו. נשתמש כאשר: נדרשת גישה לרכיבים הבונים אובייקט, בלא לחשוף את מבנהו הפנימי. נדרשת תמיכה במספר מעברים על צירוף של אובייקטים. רוצים ממשק אחיד לעבודה עם מבנים המכילים צירוף של אובייקטים.
Mediator	מגדיר אובייקט שמכמס את האופן שבו אוסף של אובייקטים מתקשרים. התבנית תומכת בצימוד רפוי, בכך שאובייקטים לא מצביעים אחד לשני באופן ישיר, אלא למתווך (Mediator), ובכך ניתן לשנות את האינטראקציה שלהם באופן עצמאי. נשתמש כאשר: קבוצה של אובייקטים מתקשרים באופן מוגדר היטב אבל מורכב. התלות הנוצרת איננה מבנית וקשה להבנה. קשה לבצע שימוש חוזר באובייקט עקב תקשורת עם מספר רב של אובייקטים. צריך לאפשר להתנהגות המבוזרת בין כמה מחלקות התאמה אישית, בלא לבצע ירושה רבה.
Memento	ללא פגיעה בכימוס, תפיסה וייחצון של המצב הפנימי של אובייקט, כך שהאובייקט יוכל להיות משוחזר למצב זה מאוחר יותר. נשתמש כאשר חלק מה-state של האובייקט חייב להישמר, כדי לשחזר אותו בעבר וגם כאשר ממשק ישיר לקבלת ה-state הפנימי עלול לחשוף את המימוש ולפגוע בהכמסה.
Null Object	משמש כברירת מחדל לאובייקט, ובכך מונע את הצורך לוודא שהאובייקט אינו null לפני שימוש בו.
Observer	מגדיר תלות של אחד לרבים בין אובייקטים, כך שכאשר אובייקט אחד משנה את מצבו, כל התלויים בו מיודעים על השינוי ומתעדכנים אוטומטית. נשתמש כאשר: כאשר להפשטה יש שני היבטים, האחד תלוי בשני. שמירת ההיבטים באובייקטים שונים מסייעת בשינוי ושימוש חוזר. שינוי של אובייקט אחד גורר שינוי באובייקט אחר, ולא ידוע מראש כמה אובייקטים יש לשנות. אובייקט צריך להודיע לאובייקטים אחרים מבלי להניח הנחות לגבי מה הם אותם אובייקטים, כלומר רוצים למנוע צימוד חזק.
Blackboard	Observer כללי המאפשר מספר קוראים וכותבים. המידע משותף לרוחב המערכת.
State	מאפשר לאובייקט לשנות את התנהגות כאשר מצבו הפנימי משתנה. האובייקט ישנה את המחלקה שבה הוא משתמש. נשתמש כאשר: התנהגות האובייקט תלויה במצבו, והוא חייב לשנותה בזמן ריצה (בתלות במצבו הפנימי). לפעולות יש תנאים גדולים, התלויים במצבו הפנימי של האובייקט. המצב מיוצג, לרוב, על ידי מונים קבועים.
Strategy	מגדיר משפחה של אלגוריתמים, מכמס כל אחד מהם, ומאפשר להחליף את השימוש בהם. ניתן לשנות את האלגוריתם באופן עצמאי בלי תלות במשתמשים במחלקה. נשתמש כאשר: הרבה מחלקות קשורות שונות רק בהתנהגותן. strategy מאפשר לקנפג מחלקה לעבודה עם מספר רב של התנהגויות. יש צורך בווריאציה של האלגוריתם. האלגוריתם משתמש במידע שלא צריך להיות חשוף ללקוח. המחלקה מגדירה הרבה התנהגויות המופיעות כסדרה של תנאים בפעולות. במקום הרבה תנאים, פשוט ניתן להעביר כל קטע קוד ל-Strategy המתאים.
Specification	צירוף לוגיקה עסקית בצורה בוליאנית (לא, או, וגם).
Template method	מגדיר שלד של אלגוריתם בפעולה, ומפנה חלק מן הצעדים לתת מחלקות. כך תת-מחלקות יכולות להגדיר מחדש צעדים מסוימים של האלגוריתם, ללא שינוי של המבנה שלו. נשתמש כאשר: נרצה לממש את החלקים הקבועים של האלגוריתם, ולאפשר למחלקות היורשות לקבוע את השאר. נרצה לרכז את ההתנהגות המשותפת של תתי המחלקות במקום אחד, כדי למנוע שכפול קוד. כשרוצים לשלוט בהרחבות המבוצעות על ידי המחלקות היורשות. ניתן להגדיר Template method הקורא לפעולות "עוגן" בנקודות מסוימות.
Visitor	מייצג פעולה לביצוע על האלמנטים של מבנה האובייקט. בכך מאפשרת התבנית להגדיר פעולה חדשה ללא צורך לשנות את המחלקות של האלמנטים שעליהם היא מבוצעת. נשתמש כאשר: האובייקט מכיל מחלקות רבות עם ממשקים שונים, ורוצים לבצע פעולות התלויות במחלקות המממשות. כאשר יש צורך להפעיל פעולות שונות ובלתי תלויות על האלמנטים המרכיבים את האובייקט, ורוצים להימנע מ"זיהום" המחלקות עם פעולות אלו. ה-Visitor מאפשר לשמור על פעולות דומות יחדיו, על ידי הגדרתם במחלקה אחת. כאשר מבנה האובייקט משותף למספר אפליקציות, ניתן להשתמש ב-Visitor כדי להכניס את הפעולות רק במקום בו הן נדרשות.

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

קישורים חיצוניים

• Design Pattern – מדיה ומימושים בנושא תבניות עיצוב (באנגלית)
• Design Pattern Blog - בלוג עם הסברים מעמיקים ומעשיים לעבודה נכונה עם תבניות עיצוב (עברית)
• Inversion of Control(הקישור אינו פעיל)
• דב זילברמן, Design Patterns, הסדרה "תבניות" וסרטונים נוספים
• תכנות מונחה עצמים