מחלקה אבסטרקטית ב-C#: מתודות אבסטרקטיות, דוגמאות והשוואה ל-interface

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

הצהרה על מחלקה אבסטרקטית

סמנו את המחלקה abstract, וסמנו abstract גם כל איבר שהמחלקות היורשות חייבות לספק, וסיימו אותו בנקודה ופסיק במקום בגוף:

using System;
using System.Collections.Generic;

abstract class Shape
{
    public string Label { get; }

    protected Shape(string label) { Label = label; }

    public abstract double Area();              // no body: each shape must implement it
    public abstract double Perimeter();

    public string Describe() =>                 // shared, concrete method
        $"{Label}: area {Area():F2}, perimeter {Perimeter():F2}";
}

class Circle : Shape
{
    private readonly double radius;
    public Circle(double radius) : base("Circle") { this.radius = radius; }

    public override double Area() => Math.PI * radius * radius;
    public override double Perimeter() => 2 * Math.PI * radius;
}

class Rectangle : Shape
{
    private readonly double width, height;
    public Rectangle(double w, double h) : base("Rectangle") { width = w; height = h; }

    public override double Area() => width * height;
    public override double Perimeter() => 2 * (width + height);
}

class Program
{
    static void Main()
    {
        var shapes = new List<Shape> { new Circle(1.5), new Rectangle(4, 2.5) };
        foreach (Shape s in shapes)
            Console.WriteLine(s.Describe());

        // var s2 = new Shape("blob"); // error CS0144: Cannot create an instance of the abstract type or interface 'Shape'
    }
}

פלט:

Circle: area 7.07, perimeter 9.42
Rectangle: area 10.00, perimeter 13.00

Describe נכתבת פעם אחת, במחלקת הבסיס, וקוראת ל-Area ול-Perimeter, שבכלל לא קיימות ב-Shape. זו בדיוק המטרה של איבר אבסטרקטי: מחלקת הבסיס יכולה לסמוך עליו, והקומפיילר מבטיח שכל צורה קונקרטית מספקת אותו. מחלקה יורשת ששוכחת אחד מהם לא עוברת קומפילציה:

class Triangle : Shape
{
    public Triangle() : base("Triangle") { }
    public override double Area() => 6;
}
// error CS0534: 'Triangle' does not implement inherited abstract member 'Shape.Perimeter()'

הפתרון הוא לממש את Perimeter, או לסמן גם את Triangle עצמה abstract אם היא בסיס ביניים למחלקות נוספות.

כללים לאיברים אבסטרקטיים

• לאיבר אבסטרקטי אין גוף והוא virtual באופן מובלע: מחלקות יורשות מממשות אותו עם override.
• רק מחלקות אבסטרקטיות יכולות להכיל איברים אבסטרקטיים. איבר כזה במחלקה רגילה הוא שגיאת קומפילציה.
• איברים אבסטרקטיים לא יכולים להיות private (אף אחד לא היה יכול לדרוס אותם) או static במחלקה.
• מתודות, מאפיינים, אינדקסרים ואירועים יכולים להיות אבסטרקטיים. שדות ובנאים לא.
• מחלקה אבסטרקטית לא חייבת להכיל אף איבר אבסטרקטי. סימון מחלקה כ-abstract לבדו רק מונע יצירת מופעים, וזה שימושי למחלקת בסיס שיש לה משמעות רק דרך תת-המחלקות שלה.

מאפיין אבסטרקטי מצהיר אילו accessors המחלקה היורשת חייבת לספק:

abstract class Plan
{
    public abstract decimal MonthlyPrice { get; }
    public abstract string Name { get; }
}

class ProPlan : Plan
{
    public override decimal MonthlyPrice => 12.99m;
    public override string Name => "Pro";
}

בנאים במחלקות אבסטרקטיות

למחלקה אבסטרקטית יכולים להיות בנאים. אי אפשר לקרוא להם עם new, אבל כל בנאי של מחלקה יורשת מריץ אחד מהם דרך : base(...), ולכן שם מאתחלים ומאמתים את המצב המשותף. הצהירו עליהם כ-protected, וזה אומר בדיוק את זה: רק מחלקות יורשות יכולות להשתמש בהם.

תבנית template method

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

using System;
using System.Collections.Generic;
using System.Text;

abstract class OrderExporter
{
    // The template: the steps and their order are fixed here.
    public string Export(IEnumerable<(string Item, int Qty, decimal Price)> rows)
    {
        var sb = new StringBuilder();
        sb.Append(Header());
        decimal total = 0;
        foreach (var r in rows)
        {
            sb.Append(Row(r.Item, r.Qty, r.Price));
            total += r.Qty * r.Price;
        }
        sb.Append(Footer(total));
        return sb.ToString();
    }

    protected abstract string Header();
    protected abstract string Row(string item, int qty, decimal price);
    protected virtual string Footer(decimal total) => "";   // optional step with a default
}

class CsvExporter : OrderExporter
{
    protected override string Header() => "item,qty,price\n";
    protected override string Row(string item, int qty, decimal price) => $"{item},{qty},{price}\n";
}

class MarkdownExporter : OrderExporter
{
    protected override string Header() => "| Item | Qty | Price |\n| --- | --- | --- |\n";
    protected override string Row(string item, int qty, decimal price) => $"| {item} | {qty} | {price} |\n";
    protected override string Footer(decimal total) => $"\nTotal: {total}\n";
}

class Program
{
    static void Main()
    {
        var rows = new List<(string, int, decimal)> { ("Coffee beans", 2, 11.50m), ("Filter papers", 1, 3.20m) };

        OrderExporter[] exporters = { new CsvExporter(), new MarkdownExporter() };
        foreach (var e in exporters)
            Console.Write(e.Export(rows) + "\n");
    }
}

פלט:

item,qty,price
Coffee beans,2,11.50
Filter papers,1,3.20

| Item | Qty | Price |
| --- | --- | --- |
| Coffee beans | 2 | 11.50 |
| Filter papers | 1 | 3.20 |

Total: 26.20

כל שורה היא tuple עם שמות, והפלט נבנה עם StringBuilder. שימו לב לשילוב: Header ו-Row הן abstract כי כל פורמט חייב להחליט עליהן, ו-Footer היא virtual עם ברירת מחדל ריקה כי רוב הפורמטים לא צריכים שם כלום. השלבים הם protected, כך שקוד חיצוני יכול לקרוא רק ל-Export. גם מחלקות ה-framework משתמשות באותו רעיון: Stream ו-TextWriter הן מחלקות בסיס אבסטרקטיות שהרבה מתודות הנוחות שלהן בנויות על מעט איברים שהמחלקה היורשת מספקת (Read ו-Write ב-stream, Write(char) ב-text writer).

מחלקה אבסטרקטית מול interface

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

Default interface methods (C# 8) צמצמו את הפער, אבל לא את ההבדל המהותי:

public interface ILogger
{
    void Write(string message);
    void Error(string message) => Write("ERROR: " + message);   // default implementation: C# 8, .NET Core 3.0+
}

מתודת ברירת מחדל עדיין לא יכולה לגשת לשדות מופע, כי ל-interface אין כאלה; היא יכולה רק לקרוא לאיברים אחרים של ה-interface.

דרך מעשית לבחור:

• Interface כשמתארים יכולת שיכולה להיות לטיפוסים שאינם קשורים זה לזה (IComparable<T>, IDisposable, IShippingProvider), כש-structs צריכים להיות מסוגלים להשתתף, או כשמחלקה צריכה כמה תפקידים כאלה. רוב הקוד של dependency injection נכתב מול interfaces מהסיבה הזו.
• מחלקה אבסטרקטית כשהטיפוסים היורשים הם באמת וריאציות של דבר אחד וחולקים מצב או אלגוריתם קבוע, כמו ה-exporters שלמעלה.
• שתיהן זה שילוב נפוץ: interface שהקוד הקורא תלוי בו, ומחלקת בסיס אבסטרקטית שמממשת אותו וחוסכת מהמממשים לכתוב מחדש את החלקים המשותפים. הדף על interfaces מכסה את הצד של ה-interface בפירוט.

טעויות נפוצות

• ניסיון ליצור מופע של מחלקת הבסיס. new Shape(...) היא CS0144. צרו מופע של מחלקה יורשת.
• שכחת override במימוש. כתיבת public double Area() במחלקה היורשת לא מממשת את האיבר האבסטרקטי; הקומפיילר מדווח CS0534 על המימוש החסר, ועוד אזהרה שהמתודה החדשה מסתירה את זו שהתקבלה בירושה.
• בנאי public במחלקה אבסטרקטית. לא מזיק, אבל מטעה. השתמשו ב-protected.
• מחלקות אבסטרקטיות בלי קוד משותף. אם למחלקת הבסיס יש רק איברים אבסטרקטיים ואין לה מצב, interface אומר את אותו הדבר ולא תופס את המקום היחיד למחלקת בסיס.
• קריאה לאיברים אבסטרקטיים מבנאי הבסיס. המימוש של המחלקה היורשת רץ לפני גוף הבנאי של המחלקה היורשת, כך שהשדות שהגוף הזה מציב עדיין 0 או null.