
sealed, כלומר מחלקה שאי אפשר לרשת ממנה. זה ההפך מהורשה רגילה, והשאלה שהוא מעלה היא מתי בכלל כדאי לחסום הורשה.sealed לפני class. בדוגמה המחלקה EmailSender שולחת מייל, והקוד לשליחה נמצא בתוכה.EmailSender, הקומפיילר מציג שגיאה: לא ניתן לרשת מטיפוס sealed.String מוגדרת כ-sealed, כי היא נפוצה מאוד ו-Microsoft לא רצתה שמפתחים ייצרו ממנה מחלקות נגזרות.הטקסט המלא של הדקות הראשונות בהרצאה «מחלקה sealed» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
הדבר הבא שאנחנו הולכים לראות גם הוא קשור לעולם ההורשה וזה פשוט מאוד מחלקה שמוגדרת כסילד. סילד זה חתום או חתומה. מה זה אומר מחלקה שהיא חתומה?
מחלקה שהיא חתומה זה אומר מחלקה שלא ניתן לרשת אותה. לכן הקונספט של סילד קשור לתחום של הורשה. אבל זה בעצם מבטל הורשה.
עכשיו, למה לנו להגביל דבר כזה? הרי אם אנחנו בונים מחלקה, למה לנו למנוע מאנשים בעתיד לרשת את המחלקה וליצור ממנה מחלקה נוספת ולהוסיף לה יכולות? אז למעשה הסיבה היא כי אין שום צורך לרשת את המחלקה הזאת בעתיד והמטרה שלה או המשמעות של המחלקה הזאת היא לא כזאת בשביל שירשו אותה.
באחד הפרויקטים הקודמים כתבנו מחלקה שנקראת person ומתארת בן אדם וכמובן שכתבנו אותה בשביל לרשת אותה ולכן לא הגיוני שהיא תהיה סילב, אבל בואו ניקח דוגמא שאנחנו רוצים בהרבה מקומות בתוכנית לבצע שליחה של אימייל, שליחה של אימייל זה פעילות מסוימת ונפרדת שאומרת שאנחנו צריכים לפתוח קו תקשורת, אנחנו צריכים להשתמש בכלים לשליחת אימייל
והקטע הקוד הזה כדאי שנשים אותו באיזושהי ישות ייעודית לשליחת אימייל. אז בעולם האובג'קט אוריינטד הגיוני שנפתח מחלקה שנקראת אימייל סנדר נגדיר במחלקה הזאת את הדאטה ממברס הדרושים יש לנו פה public string from to subject וbody נגדיר איזשהו sito break נגדיר איזשהו sito שמקבל את
כל הערכים נכניס אותם ונבנה לנו איזושהי פונקציה לשליחת האימייל כרגע מה שנעשה זה פשוט נפיץ הודעה על המסך sending subject body ויש לנו פה את סאבג'קט באדי עכשיו בואו נבדוק קודם כל שכל המחלקה עובדת כמו שצריך קונסטרקטור רדק נגדיר אותו בצורה כזאת נשים את זה סייד ביי סייד נבנה אובייקט אימייל סנדר וניתן פה כל מיני
ערכים from מוישה את gmail.com to dana את yahoo.com סאבג'קט היי באדי מסאפ נבצע אימייל נקודה send נראה שכעת יש לנו שליחה של מייל או לפחות הדגמה של שליחה של מייל אבל יכול להיות מצב שאנחנו אומרים לעצמנו אוקיי המחלקה הזאתי נועדה לשליחת מייל ובאמת היא עושה את
העבודה שלה כמו שצריך ואין שום טעם לבצע הרחבה שלה או לרשת אותה למחלקה אחרת שתהיה מסוגלת לשלוח מייל אחר או מייל יותר יפה וכולי היא כבר קיימת ועושה את התפקיד שלה כמו שצריך ואין לנו שום טעם ושום צורך ללכת לרשת אותה למחלקה אחרת במצב כזה אנחנו יכולים להגדיר את המחלקה הזאת