דפוסי עיצוב (Design Patterns): ימים יפים, ימים קשים

[הפוסט נכתב בשיתוף עם רחלי אבנר, Area Architect בחברת SAP]

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

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

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

כיצד ומדוע עלו ה Patterns לגדולה?
מדוע אם כן יש עליהן ביקורת, והאם יש לכך הצדקה?

על כך בפוסט שלפניכם.

כריסטופר אלכסנדר

שורשים

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

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

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

מ-ש-ע-מ-ם

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

עדיין, זה לא מבנה שגורם לנו להרגיש "בבית".

הנה מבנה מוצלח יותר:

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

את שרשרת ההבחנות סיכם בשלושה ספרים, שהמשמעותי ביניהם נקרא: A Pattern Language: Town, Building, Construction.

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

ספרי דפוסי העיצוב של כריסטופר אלכסנדר

דפוסי-עיצוב בתוכנה

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

את הרעש הגדול עשו ארבעה: אריך גאמה[ב] ניהל שיחה עם ריצארד הלם בה עלו הרעיונות לספר. אח"כ הם צרפו את ראלף ג'ונסון וג'ון וילידס. ארבעתם ידועים כ "Gang Of Four" (או בקיצור GOF). רובם חוקרים / בעלי רקע משמעותי של מחקר במדעי המחשב - אבל הם כתבו את הספר, כנראה הנמכר ביותר בתחום, אחד המשפיעים ביותר ושנחשב למאוד מעשי ושהקדים את "האקדמיה" בשנים.

"הספר"

בספר הם תיארו סט של בעיות תכנות - ופתרונות Object-Oriented אלגנטיים ("דפוסי עיצוב"). דגשים עקרוניים היו הפשטה וגמישות להרחבה עתידית - עקרונות החרוטים על דגלה של פרדיגמת ה Object-Oriented.

Facade, Proxy, Adapter, Singleton ועוד - הם מושגים שהטביע בעולם התוכנה ספר זה.
"דפוסי העיצוב" היו כבר קיימים בעולם: לכל דפוס עיצוב הם סיפקו מספר דוגמאות של יישומים במערכות קיימות. בספר הם אספו אותם, תיעדו אותם ויצרו שפה חדשה להנדסת תוכנה Object Oriented.

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

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


גם היום, 20 שנה אחרי, ספרים חדשים משתמשים במותג "Patterns" בכדי לקסום לנו, ולהימכר טוב יותר:

סדקים ראשונים

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

• Singletons are Pathological Liars - סינגלטונס מבלבלים והם לא OO. הם בסה"כ Global State בעולם OO. אולי אפילו - הפרה של עקרונות ה OO.
• Visitor הוא לא "שכבת הפשטה", יש לו תלות גדולה מאוד במי הוא מבקר ואז הוא כמו "משפטי If מסודרים יפה".
• הבטיחו לנו ש Patterns הם אינם תלויי-שפה, אבל פיטר נורוויג מראה שרוב ה Patterns כבר מוטמעים או מיותרים בשפות דינמיות, דפוסי עיצוב מסוימים אינם נדרשים בשפות מסוימות (ל #C יש delegate שמייתר את הצורך ב Command, דפוס העיצוב iterator הפכה לבלתי-נדרשת / implicit בשפות תכנות מודרניות רבות,  וכו').
• AreDesignPatternsMissingLanguageFeatures? וגם הוידאו הבא.

הזמן גם עבר... והאופנות קצת השתנו - ויצרו סדקים נוספים:

• תנועת האג'ייל: את התכנונים (Design) ה Top Down, החליפו ב Evolutionary Design ו Bottom Up. היכן ש Design Patterns כבר פחות מתאימים.
• בזמן הוצאת ספר דפוסי-העיצוב, תכנות OO (או תכנות מונחה היבטים - AOP) היה "הדבר הגדול הבא". היום תכנות OO הוא נפוץ מאוד - אבל "הדבר הגדול הבא" הוא משהו בין תכנות דינאמי לפונקציונלי - קצת שונה מהעקרונות של OO. לשפות אלו, דפוסי העיצוב המוכרים - פחות מתאימות.
• "אמיתות של הנדסת תוכנה" גם הן השתנו. אם פעם שימוש חוזר בקוד היה העיסוק המרכזי, היום אלו יותר פשטות של הקוד ו time-to-market. העיקרון הפתוח-סגור (Open-Closed Principle) פעם היה מאוד פופולרי (ורואים את חותמו בספר של GOF) - אך כיום הוא שנוי במחלוקת. דפוסי העיצוב מהספר של GOF מקדמים הרבה שימוש חוזר והפשטה - וקצת פחות פשטות.

את הסדק הגדול ביותר ניתן לתאר בעזרת הסיפור (לא מצאתי את המקור) על מרצה שהרצה על Design Patterns רק כדי לשים לב לאחר שנים לשאלות המוגזמות-מיסודן שמעלים אנשים: "האם עדיף להשתמש ב Flyweight או במשפט If"?
Flyweight או משפט If? האם Simplicity היא לא ערך - האם הגיוני להחליף שורת קוד אחת במבנה שלם (Flyweight)?!

דפוסי העיצוב באו להלחם בעולם עם Under-Engineering, אך יצרו עולם של Over-Engineering.

לזרוק ולשרוף?!

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

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

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

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

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

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

לו רק הייתה יותר הכוונה...

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

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

כיצד להשתמש בדפוסי עיצוב בצורה נבונה?

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

צדדים טובים:

• פתרונות מוכנים ומעולים לבעיות תכנון. נכון חלקית: אלו פתרונות טובים לבעיות מאוד מסוימות, וקיים סיכון סביר (ומוכח) - שאלו לא הפתרונות הכי טובים למערכת שלכם. זכרו: גם בספר "Design Patterns" - לא תמיד באמת מדברים עליכם.
• שפה משותפת: ברגע שגם אני וגם בין-שיחי מכירים את דפוסי העיצוב (למשל) "Strategy" - יהיה לנו הרבה יותר קל לתקשר על בעיה / פתרון טכני מסוים. מילה אחת יכולה להחליף הסבר של כמה דקות. חשוב ללמוד דפוסי-עיצוב בכדי לקבל מושגים משותף ולהפוך את התקשורת בזמן העבודה ליעילה ומדויקת יותר. כמו כן, היחסים המוכרים בין תבניות שונות מאפשרות בסיס לשיחה על מבנים מורכבים יותר (למשל: MVC). שפה משותפת היא התועלות המוסכמות ביותר בימנו המיוחסות לדפוסי-עיצוב.
• מקור השראה: לא חייבים ליישם את דפוס העיצוב כלשונו. ניתן לעשות וריאציה, ניתן לקחת רק רעיון אחד מדפוס העיצוב - ולעשות משהו אחר לגמרי. לגישה זו יש הרבה פוטנציאל, ולשם כך טוב (באופן כללי בכלל) להכיר תכנונים לא-טריוואילים של מערכות אחרות.

צדדים פחות טובים:

• הנדסת-יתר (over-engineering) - עסקנו בבעיה זו די והותר.
• פוטנציאל לקיבעון: מצב בו למישהו קשה ליישם מבנה דומה-חלקית לדפוס העיצוב, כי הוא מרגיש ש"דפוס העיצוב" חכם בוודאי ממנו - ואז הוא נגרר ליישום פחות מוצלח (אם כי שמתועד בספר אגדי).
• פוטנציאל לקיבעון כרוני: אנשים שלא מוכנים להאמין שיש פתרון טוב יותר (בהקשר המסוים) מזה המתואר בספר האגדי של "Design Patterns". לכו תשכנעו אותם.

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

הדרכים המומלצת היום להשתמש בדפוסי עיצוב הן:

• ככלל: אל תתחילו לכתוב קוד ולהשתמש בדפוסי-עיצוב. אל תעשו הכנה ל Adapters - כאשר יש רק יישום אחד מוכר. "בטח בעתיד יהיו עוד - בואו נכין את הקרקע מעכשיו" - זו לא גישה אג'ילית.
• Refactoring to Patterns - במידה והגעתם לקוד שיש בו ריחות (code smells) המצביעים על בעיה בקוד (שכפול קוד ברור, תלויות לא רצויות וכו')....
• שקלו את דפוס העיצוב המתאים. זכרו שדפוסי עיצוב מגבילים לפעמים את גמישות הקוד בכיוון מסוים. לא על כל 5 שורות קוד כפולות - כדאי להשתמש ב State, למשל.
• עשו Refactoring ושנו את הקוד כך שיישם את דפוס העיצוב שהחלטתם שהוא מוצדק - או גרסה דומה שלו. חשוב להבין "מה הקטע" של כל דפוס עיצוב - ולא סתם ליישם אותו "ע''פ הספר".

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

אפרופו: בהינתן ההבחנה ש"שפה משותפת" היא ערך עיקרי של דפוסי עיצוב ו"שימוש מופרז" היא הסכנה המרכזית - ניתן להצביע על Anti-Patterns ככלי שיכול להיות מצוין: Anti-Patterns הם תיאורים של דפוסים שליליים ולא-מומלצים מהם יש להימנע או לפחות להיזהר. אפשר לציין Anti-Patterns כגון "Gold Plating" (השקעה מופרזת באלמנט לא-חשוב), "Project Chicken" (אף אחד בפרויקט לא יכול לעמוד במשימה / לוחות הזמנים - אך כולם פוחדים להיות האדם הראשון שמודה בזה. לאחר שאחד הודה - כל השאר מצטרפים "אם הוא לא יעמוד ביעד - זה יתקע גם אותי"), "Death March" (עבודה על פרויקט ללא סיכוי הצלחה - אך מישהו "למעלה" מסרב להכיר במציאות הזו והפרויקט ממשיך) ועוד.

היופי ב Anti-Patterns הוא שאף אחד לא "ירוץ" ליישם אותם - זה לא מקור לגאווה. אין over-engineering.
החיסרון: שום מקור לא הצליח לייצר מומנטום מספיק גדול בכדי להפוך שפה כלשהי של Anti-Patterns לנפוצה מספיק בכדי שתהיה ידועה ומוסכמת בקרב קהל משמעותי [ד].

דפוסים כתהליך של התחדשות

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

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

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

Proxy ו Observer אולי הפכו לחלק משפת JavaScript (בצורת bind ו object.observe, בהתאמה) אבל עם התפתחות השפה והאתגרים שלה נוצרו גם דפוסים המתאימים להתמודדות עם האתגרים החדשים (לדוגמה: Module).

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

סיכום

• היללנו את דפוסי העיצוב.
• השמצנו וביקרנו את דפוסי העיצוב.
• לקראת הסוף: ניסינו לספק תמונה רחבה ומאוזנת.

כדאי ללמוד על דפוסי-עיצוב כשפה, תוך כדי שימוש בדוגמאות עדכניות ורלוונטיות. למשל:
במקום ללמד על Proxy על ידי ניתוח ה UML שהובא בספר של GOF ועיקרו היה מימוש פרוקסי ב ++C, אפשר להתעכב על הרעיונות שפרוקסי מייצג, ואז לראות אותם ממומשים בשפות השונות (proxy$ בספריית jQuery או bind בג'אווהסקרפיט. Dynamic Proxy בג'אווה וכו').

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

זה קצת מרתיע לכתוב על נושא כ"כ מדובר ומקובל - במיוחד כשיש גם דברי ביקורת. האם יצא רק במקרה שכתיבת הפוסט הסתיימה ביום שישי ה-13?!


שיהיה בהצלחה!



----

קישורים רלוונטיים:

דפוסי עיצוב של חווית משתמש (בעברית) וגם פרק בפודקאסט

----

[א] איש מדעי המחשב שעסק רבות ב concurrency והספריה שכתב כהשלמה לג'אווה - נכנסה מאוחר יותר לסט הספריות הסטנדרטיות.

[ב] מאוחר יותר היה שותף לכתיבת הספרייה JUnit והוביל את התכנון של סביבת הפיתוח Eclipse.

[ג] "All problems in computer science can be solved by another level of indirection", שפעם נחשב לאמת מקובלת. רפרנס: http://www.dmst.aueb.gr/dds/pubs/inbook/beautiful_code/html/Spi07g.html

[ד] והיו כמה ניסיונות, למשל הספר AntiPatterns או הספר Adrenaline Junkies and Template Zombies.

[ה] על עבודתו של אלכסנדר בתחום הארכיטקטורה אפשר לספר הרבה. הנה שני מקורות מעניינים מאד בעברית:
פרוייקט תרגום שיתופי לעברית של הדפוסים של אלכסנדר, והבלוג של יודן רופא, שהיה תלמידו של אלכסנדר
מי שקורא את מה שנכתב על עבודתו מגלה תאוריה עמוקה הרבה יותר מ"רשימת מכולת של דפוסים" וכוללת אלמנטים פילוסופיים כמו גם שיטות מעשיות להוצאה לפועל של התאוריות האלה. אגב, שיתוף משתמשים ועבודה איטרטיבית – שמוכרים היום כחלק מעקרונות האג'יליים בהנדסת תוכנה, היו גם חלק מהותי בשיטת העבודה של אלכסנדר, וניתן לקרוא עליהם בשני ספריו האחרים The Oregon experiment ו-  A Timeless way of building.