דפוס עיצוב חשוף: דפוס אסטרטגי

'

כיצד להשתמש בחבילות בג'אווה - -

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

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

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

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

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

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

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

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

איך אוכל לעשות זאת?

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

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

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

מהו תבנית אסטרטגיה?

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

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

בואו נבין תחילה את הבעיה ואז נראה כיצד תבנית אסטרטגיה יכולה לפתור את זה.

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

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

מה דעתך על העיצוב הנ'ל? יש טעות אחת גדולה בעיצוב שלנו.

כל החיות אינן יכולות לעוף, כמו במקרה הנ'ל כלב אינו יכול לעוף. אבל עדיין יש לו התנהגות 'זבוב'.

טעינו כשכתבנו את שיטת fly () המופשטת בתוך כיתת בעלי חיים. עיצוב זה יאלץ כל תת-מחלקה כלב, ציפור, פינגווין, תנין, אווז וכו 'ליישם את שיטת הזבוב ().

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

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

איך זה מרגיש לקרוא dog.fly () או crocodile.fly ().

אז, עכשיו הבנו שהתכנון שלנו לא נכון ועלינו להסיר את שיטת fly () מתת המעמד של בעלי חיים.

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

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

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

עכשיו בואו נגדיר את הממשק המעופף

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

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

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

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

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

אז בואו לשקף מחדש את הקוד שלנו לשימוש בתבנית אסטרטגיה.

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

ההבדל בין hashap ל- hashtable

אז איך כל זה עובד, בואו נראה את TestClass

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

מתי להשתמש בתבנית אסטרטגיה?

כאשר אתה רוצה להיות מסוגל לשנות את ההתנהגות בזמן הריצה באופן דינמי.

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

בשיעור העובדים לעיל אנו קובעים את שכר העובד בהתאם לייעודו. אם עובד הוא 'מתמחה' אנו מוסיפים 10% בונוס בשכר הבסיסי לחישוב השכר בפועל.

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

אז מה לא בסדר בקוד מחלקת עובדים?

ובכן, הקוד לחישוב השכר (getPay ()) הוא סטטי. נניח שאני רוצה לשנות את הבונוס עבור 'מתמחה' מ -10% ל -14%. אצטרך לפתוח את הקוד של שכבת עובדים ולשנות אותו.

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

בואו לשקף מחדש את הקוד לשימוש בתבנית אסטרטגיה.

אני הולך להגדיר כמה אלגוריתמים לחישוב השכר. אז אוכל להשתמש באל אחד מהאלגוריתמים הללו כדי לחשב את התשלום בזמן הריצה.

עכשיו, בואו נראה איך כיתת העובדים הולכת להשתנות.

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

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

אז בואו נראה את זה עובד.

C ++ לקפוץ לתור

אני מקווה שהבנת היטב את דפוס האסטרטגיה. הדרך הטובה ביותר ללמוד משהו היא על ידי תרגול.

אם יש לך שאילתות הקשורות לתבנית אסטרטגיה או תבנית אחרת, השאר את השאילתות שלך למטה.

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

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

יש לך שאלה עבורנו? הזכר אותם בסעיף ההערות ונחזור אליך.

פוסטים קשורים: