‫سلسله‌مراتب کلاس‌های بسته (Closed Class Hierarchies) در C# 15.0

// روش سنتی و قدیمی
public abstract class LegacyAnimal
{
    private protected LegacyAnimal() { } // جلوگیری از ارث‌بری خارجی
}

static string Speak(Animal animal) => animal switch
{
    Dog => "Woof",
    Cat => "Meow",
    _ => throw new InvalidOperationException() // یک کد زشت اما اجباری!
}

warning CS8509: The switch expression does not handle all possible values of its input type... 'Hamster' is not covered.

• استفاده از abstract صریح (چون خودش ضمناً abstract است).
• استفاده از sealed یا static روی کلاس پایه.

public closed class Animal { } // درست
public closed abstract class Animal { } // خطای کامپایل CS9384
public closed sealed class Animal { } // خطای کامپایل CS9381

public closed class Animal { }
public closed class Dog : Animal { } // فرزند اول خودش بسته شد
public class Labrador : Dog { }     // مجاز است

public closed class Animal<T> { }

class Dog<U> : Animal<U> { }       // مجاز (U به کلاس پایه منتقل شده)
class Horse<W> : Animal<int> { }   // خطای کامپایل CS9383 (پارامتر W رها شده است!)

public closed class Animal { }
public sealed class Dog : Animal { }
public sealed class Cat : Animal { }

// در جای دیگر کد:
Animal animal = GetAnimal();
var pet = (IPet)animal; // خطای زمان کامپایل CS0030! کامپایلر می‌داند این تبدیل همیشه شکست می‌خورد.

• Closed Class: بر پایه رابطه ارث‌بری (Is-A) کار می‌کند و فرزندان یک ریشه مشترک دارند.
• Union Support: هیچ سلسله‌مراتب و ارث‌بری در کار نیست؛ بلکه صرفاً چند نوع داده‌ایِ کاملاً مستقل (مانند ساختارهای سیستم‌عامل‌های مختلف) را در یک ظرف مشترک جمع می‌کند تا کامپایلر جامعیت آن‌ها را بررسی کند.

[Closed] 
public class Animal
{
    [CompilerFeatureRequired("ClosedClasses")] 
    public Animal() { }
}

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <LangVersion>preview</LangVersion>
</PropertyGroup>

namespace System.Runtime.CompilerServices;

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
internal sealed class ClosedAttribute : Attribute { }

• abstract (ارث‌بری کاملاً باز): هر توسعه‌دهنده‌ای در هر پروژه‌ای می‌تواند از کلاس شما ارث‌بری کند.
• sealed (انسداد کامل ارث‌بری): حتی خود شما هم در داخل همان پروژه نمی‌توانید فرزندی برای کلاس بسازید!

«این کلاس باید قابلیت ارث‌بری داشته باشد، اما فقط و فقط توسط کلاس‌هایی که خودِ من طراحی کرده‌ام.»

• CreditCardPayment
• DebitCardPayment
• BankTransferPayment

// اسمبلی شماره ۱ (DLL شما)
public closed class Animal { } // کلاس پایه بسته است

public class Mammal : Animal { } // فرزند مستقیم؛ مجاز است
public class Bird : Animal { }   // فرزند مستقیم؛ مجاز است

// پروژه خارجی
public class Lion : Animal { } // ❌ خطای کامپایل؛ ارث‌بری مستقیم غیرمجاز است

public class Lion : Mammal { } // ✅ مجاز است! چون Mammal خودش closed نشده است!

public closed class Animal { }

public closed class Mammal : Animal { } // حالا Mammal هم بسته شد
public class Dog : Mammal { }          // فقط درون همین پروژه مجاز است

public sealed closed class Animal { } // ❌ غیرمجاز!

چکیده: چندریختی شیءگرا (Polymorphism) از دیرباز یکی از ارکان بنیادی معماری نرم‌افزار در اکوسیستم دات‌نت (.NET) بوده است. این رویکرد به کمک رابط‌ها (interface) و کلاس‌های پایه انتزاعی (abstract class)، توسعه‌پذیری باز (Open Extensibility) را ممکن می‌سازد. با این حال، ماهیت نامحدود این سیستم مانع از آن می‌شود که کامپایلر بتواند تمام مشتقات یک نوع را به‌طور کامل شناسایی کند؛ پیامد این محدودیت، اجبار توسعه‌دهندگان به استفاده از الگوهای پیش‌فرض یا Fallback (مانند _ => throw ...) در تطبیق الگو (Pattern Matching) است. در بحث‌های طراحی نسخه‌های نوین سی‌شارپ (نظیر سی‌شارپ 14 و 15 و طرح‌های پیشنهادی پیشرفته زبانی)، مفاهیمی چون سلسله‌مراتب بسته (Closed Hierarchies) و انواع اجتماع یا گسسته (Union Types / Discriminated Unions) به‌منظور مدل‌سازی صریح مجموعه‌های محدود و متناهی از حالات ارائه شده‌اند. این مقاله به بررسی تحلیلی تفاوت‌های بین چندریختی باز سنتی و سلسله‌مراتب بسته، مکانیزم تطبیق الگوی جامع (Exhaustive Pattern Matching)، تأثیر آن بر نگهداری‌پذیری و صحت دامنه، جنبه‌های کارایی و سنجش عملکردی با BenchmarkDotNet، و خطاهای رایج در پیاده‌سازی می‌پردازد.

public abstract class PaymentResult
{
    private protected PaymentResult() { } // تا حدی وراثت را به داخل اسمبلی محدود می‌کند اما کامپایلر آن را بسته در نظر نمی‌گیرد
}

public sealed class PaymentSucceeded : PaymentResult
{
    public decimal Amount { get; init; }
}

public sealed class PaymentFailed : PaymentResult
{
    public string Reason { get; init; } = string.Empty;
}

static string FormatResult(PaymentResult result) => result switch
{
    PaymentSucceeded success => $"تراکنش موفق: {success.Amount}",
    PaymentFailed failure    => $"تراکنش ناموفق: {failure.Reason}",
    _                        => throw new ArgumentOutOfRangeException(nameof(result))
};

• ضرورت شاخه پیش‌فرض (_): از آنجا که کامپایلر نمی‌تواند تضمین کند که کلاس جدیدی از PaymentResult مشتق نخواهد شد، عدم استفاده از شاخه پیش‌فرض موجب هشدار (Warning) عدم جامعیت می‌گردد.
• پنهان‌سازی تغییرات دامنه: اگر عضوی تحت عنوان PaymentPending به دامنه اضافه شود، کدهای قدیمی بدون هیچ خطای کامپایلی کامپایل می‌شوند، اما در زمان اجرا با استثنای پیش‌بینی‌نشده (ArgumentOutOfRangeException) مواجه خواهند شد.

public record class PaymentSucceeded(decimal Amount);
public record class PaymentFailed(string Reason);

// تعریف نوع اجتماع (بسته)
public union PaymentResult(
    PaymentSucceeded,
    PaymentFailed);

static string FormatResult(PaymentResult result) => result switch
{
    PaymentSucceeded success => $"تراکنش موفق: {success.Amount}",
    PaymentFailed failure    => $"تراکنش ناموفق: {failure.Reason}"
};

نکته کلیدی معماری: پرسش اصلی این نیست که کدام روش مدرن‌تر یا سریع‌تر است؛ بلکه پرسش بنیادی مهندسی این است: آیا دامنه این نوع داده باید ذاتاً باز باشد یا بسته؟

public record class Pending;
public record class Paid;
public record class Cancelled;
public record class Refunded;

public union OrderState(
    Pending,
    Paid,
    Cancelled,
    Refunded);

public static class OrderPolicy
{
    public static string GetStatusMessage(OrderState state) => state switch
    {
        Pending   => "در انتظار پرداخت",
        Paid      => "پرداخت انجام شد",
        Cancelled => "سفارش لغو شد",
        Refunded  => "مبلغ به مشتری عودت داده شد"
    };
}

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser]
public class DispatchBenchmark
{
    private readonly PaymentResult _unionResult = new PaymentSucceeded(100m);
    private readonly PaymentResultBase _traditionalResult = new PaymentSucceededBase(100m);

    [Benchmark(Baseline = true)]
    public string TraditionalDispatch() => ProcessTraditional(_traditionalResult);

    [Benchmark]
    public string UnionDispatch() => ProcessUnion(_unionResult);

    private static string ProcessUnion(PaymentResult result) => result switch
    {
        PaymentSucceeded success => success.Amount.ToString(),
        PaymentFailed failure    => failure.Reason
    };

    private static string ProcessTraditional(PaymentResultBase result) => result switch
    {
        PaymentSucceededBase success => success.Amount.ToString(),
        PaymentFailedBase failure    => failure.Reason,
        _                            => throw new ArgumentOutOfRangeException(nameof(result))
    };
}

توصیه اجرایی: همواره بنچمارک‌ها را تحت پیکربندی Release و در محیط ایزوله اجرا کنید (dotnet run -c Release). از استناد به نتایج تئوریک بدون سنجش بر روی سناریوهای بار کاری واقعی اجتناب ورزید.

public interface IPaymentGateway
{
    Task<ExecutionResult> ProcessAsync(PaymentDetails details, CancellationToken ct);
}
// ارائه‌دهندگان مختلف می‌توانند آزادانه به پروژه اضافه شوند:
// StripeGateway, ZarinPalGateway, PayPalGateway, ...

• نتایج توابع (مانند ساختارهای Result و اعتبارسنجی‌ها)
• پیام‌های پروتکل و بسته‌های ارتباطی داخلی
• دستورات متناهی در معماری‌های CQRS / Event-Sourcing
• ماشین‌های وضعیت (State Machines)

• استفاده از Union برای انتزاعات توسعه‌پذیر: تعریف اجتماع روی سرویس‌هایی که باید با افزونه‌ها گسترش یابند، کوپلینگ شدید و شکنندگی ایجاد می‌کند.
• افزودن کورکورانه شاخه پیش‌فرض (_): قرار دادن _ => ... در تطبیق الگوهای بسته، اصلی‌ترین مزیت این ویژگی (ایمنی کامپایلر در برابر تغییرات مدل) را بی‌اثر می‌کند.
• اشتباه گرفتن جامعیت نوع با درستی منطق بیزینس: کامپایلر اطمینان می‌دهد که تمام حالات بررسی شده‌اند؛ اما نمی‌تواند صحت محاسبات را ارزیابی کند. برای مثال:

// کامپایلر این کد را تایید می‌کند، اما منطق بیزینس معکوس و نادرست است!
return result switch
{
    PaymentSucceeded => "خطا در تراکنش",
    PaymentFailed    => "تراکنش موفق"
};

• بنابراین تست‌های یکپارچگی و Unit Test همچنان غیرقابل جایگزین هستند.

• برای دامنه‌های باز و توسعه‌پذیر، از چندریختی باز و رابط‌ها بهره بگیرید.
• برای دامنه‌های بسته و حالت‌های متناهی، از ساختارهای بسته و تطبیق الگوی جامع استفاده کنید.

// درون Assembly مرجع (مثلاً CoreLib.dll)
public closed record class Shape;
public record class Circle : Shape;
internal record class Triangle : Shape; // فقط داخل این پروژه دیده می‌شود

• توسعه‌دهنده کلاس Circle را می‌بیند، اما به Triangle دسترسی ندارد.
• از دیدگاه مصرف‌کننده خارجی، ساختار ارث‌بری به‌طور کامل برای او شفاف نیست.
• نتیجه: کامپایلر اجازه حذف بازوی _ یا default را به پروژه‌های خارجی نمی‌دهد!

• فرض کنید یک پکیج مالی به نام Billing منتشر کرده‌اید که نوع PaymentMethod را با سه فرزند مستقیم Cash، Card و BankTransfer اکسپوز کرده است.
• مصرف‌کنندگان در پروژه‌های خود سوییچ‌های جامع (بدون default) نوشته‌اند و کد به‌خوبی کار می‌کند.
• در نسخه بعد، شما تصمیم می‌گیرید نوع جدیدی مانند Crypto اضافه کنید و نسخه پکیج را به‌صورت جزئی (Minor Bump، مثلاً ۱.۱ به ۱.۲) ارتقا دهید؛ چراکه از نظر شما قابلیت جدیدی افزوده شده و کدهای قبلی تغییر نکرده‌اند.
• فاجعه: خط لوله CI/CD پروژه‌های مشتریانی که وابستگی‌ها را به‌صورت خودکار به‌روزرسانی می‌کنند، در اولین بیلد با خطای کامپایل مواجه می‌شود؛ چون سوییچ‌های جامع آن‌ها دیگر پوشش‌دهنده عضو چهارم نیستند!

قانون طلایی برای توسعه‌دهندگان پکیج: افزودن فرزند مستقیم جدید به یک سلسله‌مراتب بسته عمومی، رفتاری مشابه افزودن مقادیر جدید به enum دارد. این کار باید یک Breaking Change تلقی شده و همراه با ارتقای نسخه اصلی (Major Version Bump) منتشر شود.

public closed record class PaymentMethod;

public sealed record class Cash : PaymentMethod;

// کلاس Card مهروموم (sealed) نمی‌شود تا نقطه توسعه بیرونی باقی بماند
public record class Card(string Last4) : PaymentMethod;

• کاربران بیرونی نمی‌توانند مستقیماً از PaymentMethod ارث‌بری کنند.
• اما می‌توانند از Card ارث‌بری کرده و مثلاً PrepaidCard : Card بسازند.
• در سوییچ‌های موجود کاربران، متغیر PrepaidCard همچنان با بازوی Card card => ... تطبیق داده می‌شود و کدهای بیرونی دچار شکست در کامپایل نمی‌شوند.

• کلاس‌های بسته (Closed Hierarchies): بر اساس مالکیت و ارث‌بری مشترک کار می‌کنند. همه گزینه‌ها توافق کرده‌اند که از یک کلاس ریشه مشترک ارث ببرند (Dog : Animal). این ابزار زمانی ایده‌آل است که شما مالک کل ساختار دامنه هستید.
• اتحادیه‌ها (Union Types): بر اساس بسته‌بندی انواع مستقل و بی‌ارتباط کار می‌کنند. برای مثال در public union Pet(Cat, Dog);، کلاس‌های Cat و Dog هیچ ریشه مشترکی ندارند و اصلاً نمی‌دانند که عضو یک اتحادیه هستند. این مفهوم مناسب زمانی است که انواع از کتابخانه‌های متفرقه وارد شده‌اند یا نباید ساختار شیءگرایی یکسانی به آن‌ها تحمیل شود.

• جاوا (Java 21): از کلمه کلیدی sealed با بند صریح permits استفاده می‌کند. کلاس‌های Sealed در جاوا لزوماً abstract نیستند، اما در #C کلمه کلیدی جدید closed به کار گرفته شده و نوع پایه ذاتاً abstract فرض می‌شود و لیست فرزندان از محدوده اسمبلی استنتاج می‌شود.
• کاتلین و اسکالا: مفهوم sealed class و sealed trait به عنوان ساختار اصلی زبان عمل می‌کند، در حالی که در #C رفتار ارث‌بری متداول مبتنی بر Reference Type حفظ شده و بنابراین هر نمونه همچنان روی Heap تخصیص حافظه (Allocation) دارد و از رفتار Value Types (مانند Sum Types در F# یا Rust) متمایز است.

• پشتیبانی در سریالایزرها (مانند System.Text.Json): مسئله مهم، نگاشت خودکار این سلسله‌مراتب در داده‌های چندریختی JSON است (طبق Issue شماره dotnet/runtime #129041) تا نیازی به تعریف دستی فیلدهای Discriminator نباشد.
• پشتیبانی از Interfaceها: در پیش‌نمایش فعلی، این ویژگی تنها مختص کلاس‌ها و رکورد-کلاس‌ها است و اعمال آن روی Interfaceها همچنان در کارگروه طراحی زبان (LDM) در حال بررسی است.
• تغییر نام‌های موقت: نام اتریبیوت کامپایلر در پروپوزال رسمی ممکن است در نسخه نهایی بین ClosedAttribute یا IsClosedTypeAttribute تغییر کند.