ראשי > decorator pattern > חלק שני The Decorator המבנה הכללי: להלן המבנה הכללי של ה decorator pattern. למי שעדיין אינו זוכר כיצד להסתכל בדיאגרמה זו זה הזמן להתרענן: לחץ להגדלה - decorator מיהם החברים בחגיגה?: Component (VisualComponent) - מגדיר ממשק עבור האובייקטים שאפשר (ושנרצה) להוסיף להם תחומי אחריות באופן דינמי. ConcreteComponent (TextView) - מגדיר אובייקט שאליו נחבר תחומי אחריות נוספים. Decorator - שומר הצבעה לאובייקט Component ומגדיר ממשק שמציית לממשק של ה Componet. ConcreteDecorator (BorderDecorator, ScrollDecorator) - מוסיף תחומי אחריות ל Component. מתי נשתמש בdecorator pattern?: כשנרצה להוסיף תחומי אחריות לאובייקטים אינדיווידואליים באופן דינמי ושקוף, כלומר מבלי להשפיע על אותם אובייקטים. כאשר הרחבה על ידי subclassing אינה מעשית. לעתים קיים מספר גדול של הרחבות אפשריות, דבר שיגרום לכמויות עצומות של subclass ים אם ניצור subclass עבור כל קומבינציה אפשרית ביניהן. מקרה אחר שלא ניתן להשתמש ב subclassing הוא כאשר אין בידינו את ההגדרה המקורית של ה class או שבאופן אחר הוא אינו זמין ל subclassing. יחסי העבודה: Decorator מעביר בקשות לאובייקט Component שלו. ייתכן והוא מבצע פעולות נוספות לפני או לאחר העברת הבקשה. יתרונות וחסרונות: ל decorator pattern ישנם לפחות שני יתרונות ושני חסרונות: גמישות רבה יותר מהורשה סטטית -ה decorator pattern מספקת דרך יותר גמישה להוספת אחריות לאובייקט מאשר הורשה סטטית (מרובה). בעזרת decorator ים, תחומי אחריות יכולים להיות מוספים ומורדים בזמן ריצה, פשוט על ידי חיבור או ביטול שלהם. זאת בניגוד להורשה, שמחייבת ליצור subclass חדש לכל אחריות נוספת (למשל BorderedScrollableTextBiew וכו'). זה יוצר כמות עצומה של class ים ומסבך את המערכת. כמו כן, הוספה של Decorator ים שונים עבור Component מסוים מאפשר לנו לערבב ולהתאים תחומי אחריות שונים. Decorator ים מאפשרים להוסיף תכונה כלשהי פעמיים בקלות. למשל כדי לתת ל Textview גבול כפול, פשוט נחבר שני BorderDecorators. נסו לבצע פעמיים הורשה מ Border כדי להוסיף זאת... הקומפיילר לא יאהב זאת... הימנעות ממצב של class ים עתירי תכונות שנמצאים במעלה ההיררכיה - ה decorator pattern מציעה גישה של "שלם לפי כמה שאכלת" בקשר להוספת תחומי אחריות לאובייקטים. במקום לנסות לתמוך מראש בכל הקומבינציות של מאפיינים הנראות לעין, בתוך class מסובך ומורכב, כאן מגדירים class פשוט ומוסיפים לו פונקציונליות באופן הדרגתי בעזרת אובייקטי Decorator. כאן הפונקציונליות מורכבת מחלקים פשוטים וקטנים. כתוצאה מכך האפליקציה לא צריכה לשלם עבור פונקציונליות שהיא אינה משתמשת בה. דבר נוסף, קל להגדיר סוגים חדשים של Decorator ים באופן בלתי תלוי. לעומת זאת כאשר מנסים להרחיב class מורכב, זה נוטה לגרום לחשיפת פרטים שאינם קשורים לפונקציונליות הנוספת שהוספנו לו. Decorator וה Component ים שלו אינם זהים - Decorator מתפקד כעטיפה שקופה אך מבחינת זהויות אובייקטים component שעבר דקורציה אינו זהה ל component המקורי. לכן כאשר נרצה להשוות בין אובייקטים צריך לזכור שהתוצאה תהיה כאן שלילית, כלומר לא נוכל לדעת שהאובייקט היה מאותו סוג בזמן שנערוך השוואה ביניהם (למשל על ידי אופרטור =). הרבה אובייקטים קטנים - design שמשתמש ב Decorator מתאפיין פעמים רבות במערכת שכוללת המון אובייקטים קטנים שכולם נראים דומים. האובייקטים שונים רק באופן שבו הם מקושרים, ולא במחלקה שאליה הם משתייכים או בערך המשתנים שלהם. למרות שמערכות אלה קלות להתאמה ולתפעול על ידי מי שמבין אותן, הן עלולות להיות קשות ללמידה ול debugging.   מה בעמוד:   המבנה המשתתפים מתי נשתמש יחסי העבודה בעד ונגד