the strategy pattern

ראשי > strategy pattern > חלק שני

The Strategy

המבנה הכללי:
להלן המבנה הכללי של ה Strategy pattern. אם אינכם זוכרים את הסימונים בדיאגרמה זה הזמן להתרענן .

לחץ להגדלה - strategy

מיהם החברים בחגיגה?:

Strategy (Compositor) - מגדיר ממשק משותף לכל האלגוריתמים הנתמכים. המחלקה Context תשתמש בממשק זה כל מנת לקרוא לאלגוריתם שמוגדר על ידי ConcreteStrategy.
ConcreteStrategy (SimpleCompositor, etc.) - מממש את האלגוריתם תוך שימוש בממשק של Strategy.
Context (Composition) - מכיל אובייקט ConcreteStrategy שמוכנס אליו. מחזיק הצבעה לאובייקט Strategy (להצבעה זו נבצע את ההשמה של ה ConcreteStrategy). יתכן והוא יגדיר ממשק שיאפשר ל Strategy להיכנס ל data שלו.

מתי נשתמש בstrategy pattern?:

כאשר הרבה class ים שקשורים זה לזה שונים אחד מהשני רק בהתנהגות שלהם. Strategy ים מספקים דרך לקבוע class אחד שבוחר התנהגות אחת מתוך מספר התנהגויות.
כאשר נצטרך וריאציות שונות של אותו אלגוריתם. למשל, יתכן ונצטרך להגדיר אלגוריתמים דומים שמספקים יחסי זמן-מקום שונים. במקרה זה ניתן להשתמש ב strategy ים כאשר הווריאנטים השונים של האלגוריתם ממומשים כהיררכית מחלקות של אלגוריתמים.
כאשר אלגוריתם משתמש ב data שהקליינט לא אמור לדעת עליה. נשתמש ב strategy pattern כדי להימנע מלחשוף מבני נתונים מורכבים שספציפיים לאלגוריתם עצמו.
כאשר class מגדיר מספר התנהגויות, והן מופיעות כמספר conditional statements בפעולות שלו. במקום שיהיו לנו ביטויי תנאי רבים, נכניס כל אחת מתוצאות התנאי ל strategy class משלה.

יחסי העבודה:

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

יתרונות וחסרונות:
ל strategy pattern יש את היתרונות והחסרונות הבאים:

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

אלטרנטיבה ל subclassing - הורשה מציעה דרך אחרת לתמוך באפשרות למספר אלגוריתמים והתנהגויות. אפשר לבצע subclassing ל Context באופן ישיר על מנת לתת לו התנהגויות שונות. אבל זה קושר בחוזקה את ההתנהגות ל Context. זה מערבב את מימוש האלגוריתם עם המימוש של ה Context, מה שמקשה יותר על הבנת מחלקת ה Context, על התחזוקה שלה ועל ההרחבה שלה. כמו כן, לא ניתן לשנות את האלגוריתם באופן דינמי. התוצאה הסופית היא שנישאר עם הרבה class ים שההבדל היחיד ביניהם הוא האלגוריתם או ההתנהגות שהם מחזיקים. ריכוזיות של האלגוריתם בתוך class נפרד מאפשר לנו לשנות את האלגוריתם באופן בלתי תלוי ב Context, דבר שמקל על ההחלפה שלו, הבנה שלו והרחבה שלו.
Strategy ים חוסכים את הצורך בביטויי תנאי - ה strategy pattern מציעה אלטרנטיבה לביטויי תנאי עבור בחירת סוג של התנהגות רצויה מתוך מספר סוגים. כאשר מספר התנהגויות נכללות באותו ה class , קשה להימנע מלהשתמש בביטויי תנאי על מנת לבחור את סוג ההתנהגות הרצוי. בכך שאנו מרכזים את ההתנהגות ב class נפרד אנו מבטלים את הצורך בביטויי תנאי. לדוגמה, ללא strategy ים הקוד לשבירת טקסט לשורות היה נראה כך:

void Composition::Repair() {
     switch(_breakingStrategy) {
     case SimpleStrategy:
         ComposeWithSimpleCompositor();
         break;
     case TeXStrategy:
         ComposeWithTeXCompositor();
         break;
     // ...
     }
     // merge results with existing composition,
     if necessary
}

ה strategy pattern מבטלת את הצורך בביטוי התנאי בכך שהיא שולחת את משימת שבירת השורות לאובייקט strategy:

void Composition::Repair() {
     _compositor->Compose();
     // merge results with existing composition,
     // if necessary
}

קוד המכיל ביטויי תנאי רבים לעתים מרמז על הצורך להשתמש ב strategy pattern.
בחירה בין מימושים שונים - strategy ים יכולים לספק מימושים שונים לאותה ההתנהגות. הקליינט יוכל לבחור בין strategy ים שמממשים את אותה ההתנהגות,כל אחד עם יחס זמן-מקום שונה.
קליינטים חייבים להיות מודעים לסוגים השונים של ה strategy ים - ל strategy pattern ישנו מכשול פוטנציאלי בכך שהקליינט חייב להבין במה ה strategy ים שונים אחד מהשני לפני שיוכל לבחור את המתאים לו. קליינטים עלולים להיחשף לחלקים במימוש. לכן נשתמש ב strategy pattern רק כאשר השינויים בין ההתנהגויות הם רלוונטיים לקליינט.
עיכובים מיותרים בתקשורת בין Strategy ל Context - הממשק של Strategy הוא משותף לכל ה ConcreteStrategy ים, בין אם הם מממשים אלגוריתם טריוויאלי ובין אם הם מממשים אלגוריתם מסובך. עקב כך, יתכן וחלק מה ConcreteStrategy ים לא ישתמשו בכל האינפורמציה שנשלחת אליהם דרך ממשק זה, ואפילו יתכן והפשוטים שביניהם לא ישתמשו בה כלל! משמעות הדבר היא שיהיו מקרים בהם ה Context יוצר ומאתחל פרמטרים שלא ייעשה בהם שימוש. במקרים בהם בעיה זו משמעותית, נצטרך coupling הדוק יותר בין Context ל Strategy.
הגדלת מספר האובייקטים - strategy ים מגדילים את מספר האובייקטים באפליקציה. לעתים ניתן להקטין את הבעיה על ידי שימוש באובייקטים חסרי מצב, אשר ה Context ים יכולים לבצע בהם sharing. במקרים אלה, אם נצטרך לשלוח מידע כלשהו על מצב, ה Context יטפל בזה וישלח את המידע כבקשה ל Strategy.

מה בעמוד:

המבנה
המשתתפים
מתי נשתמש
יחסי העבודה
בעד ונגד