מבוא לתבנית האובייקט האפס
1. סקירה כללית
במדריך מהיר זה, נסתכל על תבנית האובייקט Null, מקרה מיוחד של דפוס האסטרטגיה. נתאר את מטרתו ומתי עלינו לשקול להשתמש בה.
כרגיל, נספק דוגמת קוד פשוטה.
2. דפוס אובייקט אפס
ברוב שפות התכנות מונחות האובייקטים, אסור לנו להשתמש ב- ריק התייחסות. לכן אנו נאלצים לכתוב לעתים קרובות ריק צ'קים:
Command cmd = getCommand (); אם (cmd! = null) {cmd.execute (); }לפעמים, אם מספר כזה אם ההצהרות מתגברות, הקוד עלול להיות מכוער, קשה לקריאה ומועד לטעויות. זה כאשר דפוס האובייקט האפס עשוי להועיל.
הכוונה של תבנית האובייקט האפס היא למזער סוג כזה של ריק חשבון. במקום זאת, אנו יכולים לזהות את התנהגות ה- null ולעטוף אותה בסוג המצופה בקוד הלקוח. לעתים קרובות יותר אז לא, היגיון נייטרלי כזה הוא פשוט מאוד - אל תעשו כלום. בדרך זו אנחנו כבר לא צריכים להתמודד עם טיפול מיוחד ב ריק הפניות.
אנו עשויים פשוט להתייחס לאובייקטים null באותו אופן בו אנו מתייחסים לכל מופע אחר מסוג מסוים המכיל למעשה היגיון עסקי מתוחכם יותר. כתוצאה מכך, קוד הלקוח נשאר נקי יותר.
מכיוון שלאובייקטים null אין מצב כלשהו, אין צורך ליצור מופעים זהים מספר פעמים. כך, לעתים קרובות ליישם אובייקטים אפסיים כמו יחידים.
3. דיאגרמת ה- UML של תבנית האובייקט האפס
בואו נסתכל על התבנית באופן חזותי:
כפי שאנו רואים, אנו יכולים לזהות את המשתתפים הבאים:
- לָקוּחַ דורש מופע של תקציר אובייקט
- תקציר אובייקט מגדיר את החוזה לָקוּחַ מצפה - הוא עשוי להכיל גם לוגיקה משותפת לשיעורי היישום
- RealObject מכשירים תקציר אובייקט ומספק התנהגות אמיתית
- NullObject מכשירים תקציר אובייקט ומספק התנהגות ניטרלית
4. יישום
עכשיו שיש לנו מושג ברור לגבי התיאוריה, בואו נסתכל על דוגמא.
דמיין שיש לנו יישום לנתב הודעות. יש להקצות עדיפות חוקית לכל הודעה. המערכת שלנו אמורה לנתב הודעות בעדיפות גבוהה לשער SMS ואילו הודעות עם עדיפות בינונית צריכות להיות מנותבות לתור JMS.
מעת לעת, עם זאת, הודעות עם עדיפות "לא מוגדרת" או ריקה עשויה להגיע ליישום שלנו. יש להשליך הודעות כאלה מעיבוד נוסף.
ראשית, ניצור את נתב מִמְשָׁק:
ממשק ציבורי נתב {void route (Message msg); }לאחר מכן, בואו ניצור שתי יישומים של הממשק הנ"ל - זו שאחראית לניתוב לשער SMS וזו שתנתב את ההודעות לתור JMS:
מחלקה ציבורית SmsRouter מיישמת את הנתב {@Override נתיב הריק הציבורי (הודעת הודעה) {// פרטי היישום}}המחלקה הציבורית JmsRouter מיישמת את הנתב {@Override נתיב הריק הציבורי (הודעת הודעה) {// פרטי היישום}}סוף כל סוף, בואו נשתמש באובייקט האפס שלנו:
המחלקה הציבורית NullRouter מיישמת את הנתב {@Override מסלול הריק הציבורי (הודעה msg) {// אל תעשה כלום}}עכשיו אנחנו מוכנים להרכיב את כל החלקים. בואו נראה איך נראה קוד הלקוח לדוגמא:
מחלקה ציבורית RoutingHandler {ידית חלל ציבורית (הודעות ניתנות לשינוי) {עבור (הודעת מסר: הודעות) {נתב נתב = RouterFactory.getRouterForMessage (msg); router.route (msg); }}}כמו שאנו יכולים לראות, אנו מתייחסים לכולם נתב חפצים באותו אופן, לא משנה איזה יישום מוחזר על ידי RouterFactory. זה מאפשר לנו לשמור על הקוד שלנו נקי וקריא.
5. מתי להשתמש בתבנית האובייקט האפס
עלינו להשתמש בתבנית האובייקט האפס כאשר לָקוּחַ אחרת היה בודק אם ריק רק כדי לדלג על ביצוע או לבצע פעולת ברירת מחדל. במקרים כאלה, אנו עשויים להכיל את ההיגיון הנייטרלי בתוך אובייקט null ולהחזיר אותו ללקוח במקום ל- ריק ערך. בדרך זו קוד הלקוח כבר לא צריך להיות מודע אם מקרה נתון הוא ריק או שלא.
גישה כזו עוקבת אחר עקרונות כלליים מונחים עצמים, כמו Tell-Don't-Ask.
כדי להבין טוב יותר מתי עלינו להשתמש בתבנית ה- Null Object, בואו נדמיין שעלינו ליישם CustomerDao ממשק המוגדר כדלקמן:
ממשק ציבורי CustomerDao {Collection findByNameAndLastname (שם מחרוזת, שם מחרוזת); לקוח getById (מזהה ארוך); }רוב היזמים היו עושים זאת לַחֲזוֹר Collections.emptyList () מ findByNameAndLastname () במקרה שאף אחד מהלקוחות לא תואם קריטריוני החיפוש שסופקו. זו דוגמה טובה מאוד למעקב אחר תבנית האובייקט Null.
לעומת זאת, ה לקבלById () צריך להחזיר את הלקוח עם הזהות הנתונה. מישהו שמתקשר לשיטה זו מצפה לקבל את ישות הלקוח הספציפית. במקרה שלא קיים לקוח כזה עלינו לחזור במפורש ריק כדי לאותת שיש משהו לא בסדר בזהות המסופקת.
כמו בכל שאר הדפוסים, עלינו לשקול את מקרה השימוש הספציפי שלנו לפני שיישם באופן עיוור את תבנית האובייקט Null. אחרת, אנו עשויים להכניס לקוד שלנו כמה באגים שקשה למצוא.
6. מסקנה
במאמר זה למדנו מהו תבנית האובייקט Null ומתי אנו עשויים להשתמש בו. יישמנו גם דוגמה פשוטה לדפוס העיצוב.
כרגיל, כל דגימות הקוד זמינות ב- GitHub.
