212. sealed methods

ראינו פעם שעברה שאפשר להפוך מחלקה לsealed, דבר המונע ממפתחים אחרים לרשת מהמחלקה שלנו.

משהו פחות מוכר זה האפשרות להפוך מתודה לsealed. מה זה אומר?

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

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

למשל:

public class Rectangular : Shape
{
    protected readonly Edge[] mEdges = new Edge[4];

    public sealed override intGetPerimiter()
    {
        return mEdges.Sum(x => x.Length);
    }
}

כעת אם ננסה לדרוס את היקפו של ריבוע, לא נוכל יותר:

public class Square
{
    public override int GetPerimiter()
    {
        return 4 * mEdges.First().Length;
    }
}

נקבל שגיאת קימפול:

Error: ‘Square.GetPerimiter()’: no suitable method found to override

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

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

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

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

למעשה, כאשר הופכים מחלקה לsealed, הקומפיילר הופך את כל המתודות בה לsealed באופן implicitly.

המשך יום פחות סגור טוב,