מי עדיין משתמש ב-Design Patterns? [בעד ונגד]

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

מקור: Shutterstock

מקור: Shutterstock

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

שוחחתי לפני כשבוע עם ארכיטקט ותיק בחברת תוכנה ישראלית. סיפרתי לו שאנו מעבירים קורס של Design Patterns בחברה. “למה?!” – הוא שאל, תופס את ראשו בידיו במבט מיוסר. “כן, גם אני לא מתלהב מהנושא” עניתי. “אבל אנשים רוצים. מה, נמנע מהם את הידע הזה?”.

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

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

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

מתחילים בבסיס

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

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

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

מקור: Rodeore

מקור: Rodeore

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

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

מקור: Flickr, cc-by n_willsey

מקור: Flickr, cc-by n_willsey

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

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

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

מקור: ליאור בר-און

מקור: ליאור בר-און

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

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

את הרעש הגדול עשו ארבעה: אריך גאמה (שהיה שותף לכתיבת הספרייה JUnit והוביל את התכנון של סביבת הפיתוח Eclipse) ניהל שיחה עם ריצ’ארד הלם בה עלו הרעיונות לספר. אח”כ הם צרפו את ראלף ג’ונסון וג’ון וילידס. ארבעתם ידועים כ-“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 שהופיעו בספר:

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

  • תנועת האג’ייל: את התכנונים (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.

מקור: Shutterstock

מקור: Shutterstock

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

לפני שאתם שולחים את הספר של 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 לנפוצה מספיק בכדי שתהיה ידועה ומוסכמת בקרב קהל משמעותי. היו כמה ניסיונות, למשל הספר AntiPatterns או הספר Adrenaline Junkies and Template Zombies.

מקור: Shutterstock

מקור: Shutterstock

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

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

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

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

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

סיכום

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

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

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

Avatar

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

7 תגובות על "מי עדיין משתמש ב-Design Patterns? [בעד ונגד]"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אורי
Guest

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

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

Design Pattern הם מעולים, אבל רק שיש להם באמת הצדקה.

גבר
Guest

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

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

design patterns זה דבר שאם אתה לא באמת שולט ומבין אותו, עדיף לא להשתמש בו בכלל.

גבר גבר
Guest

יא גבר

נמרוד
Guest

הדרך לשלות בנושא הוא על ידי נישוי ותהייה
לכן אתה מציע לא להשתמש אף פעם ב design patterns ?

נמרוד
Guest

עבדתי בפרוייקט שהכול היה פרוצדורלי ואכשיו בפרוייקט שסובל מעודף PATTERNS,
ראיתי איך נופלים עם SOLID וב SOA – אני חושב שהנכון הוא להתאים את העיצוב למתכנתים
ול” איתני הטבע ” – ו Design Patterns לעסות במסורה – אם יש PATTERN מתאים הוא צריך ליקפוץ לעיינים בצורה ברורה ולא צריך לחפס אותו.

עודד
Guest

הסיבות שלדעתי יש ירידה בפופולריות של ה design patterns:
1) ההתפתחות של הספריות וה frameworks – עושות את זה בשבילך
2) המעבר לפיתוח אפליקציות ווביות קלילות יותר – פחות צורך.
3) אולי גם המעבר לאג’ייל

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

Dor
Guest

כתבה מעולה. בסופו של יום , מי שמשתמש במידה נכונה ב Design Patterns יכול להגיע לתוצאות יפות. לצערי , היום רוב האנשים בקושי מכירים תבניות. אם לדוגמה תשאל את רוב הסטודנטים , ,תגלה שבמקרה הטוב הם יוכלו להגיד לך שהם מכירים את התבנית Factory Pattern ושם זה נגמר בדרך כלל.
מי שרוצה ללמוד , יש אינספור מדריכים באינטרנט , אינספור ספרים ואינספור סרטונים.
אתר נחמד שמצאתי (שהוא גם ישראלי) , הוא http://designpattern.co.il/index.html
וזאת אחלה של דרך להתחיל למי שקצת אבוד בחיפושים.

wpDiscuz

תגיות לכתבה: