🚨 قابلیت جدید field در C# 14 همیشه هم بی‌خطر نیست!

یکی از جذاب‌ترین قابلیت‌های C# 14 معرفی کلیدواژه field است.
به کمک آن دیگر لازم نیست برای هر Property یک Backing Field جداگانه تعریف کنید.
قبلاً می‌نوشتیم:

private decimal _price;

public decimal Price
{
    get => _price;
    set => _price = value;
}

حالا می‌توانیم بنویسیم:

public decimal Price
{
    get;
    set => field = value;
}

کد تمیزتر، خواناتر و Boilerplate کمتر...
اما یک نکته مهم وجود دارد که خیلی‌ها به آن توجه نمی‌کنند. 👇

⚠️ مشکل از کجا شروع می‌شود؟

وقتی از field استفاده می‌کنید، دیگر فیلدی به نام _price وجود ندارد.
کامپایلر خودش یک Backing Field مخفی ایجاد می‌کند.
چیزی شبیه:

<Price>k__BackingField

این یعنی اگر جایی از پروژه مستقیماً به _price وابسته باشد...
ممکن است برنامه بدون هیچ خطای کامپایل، در Runtime دچار مشکل شود.

🔥 یکی از رایج‌ترین قربانی‌ها: EF Core

فرض کنید قبلاً این Mapping را نوشته‌اید:

builder.Property(x => x.Quantity)
       .HasField("_quantity");

بعد تصمیم می‌گیرید از قابلیت جدید C# 14 استفاده کنید.

public int Quantity
{
    get;
    set => field = value;
}

نتیجه؟
هنگام اجرای برنامه با خطای:

InvalidOperationException

روبه‌رو خواهید شد.
چون دیگر فیلدی به نام _quantity وجود ندارد.

⚠️ ءReflection هم ممکن است از کار بیفتد
کدهایی مانند:

GetField("_quantity")

یا

GetRuntimeField(...)

بعد از Refactor مقدار null برمی‌گردانند.
و معمولاً چند خط بعد...
به یک NullReferenceException ختم می‌شوند.

✅ قبل از استفاده از field این موارد را بررسی کنید

🔹 تمام HasField(...)های پروژه
🔹 ءAttributeهای BackingField
🔹 استفاده از Reflection
🔹 ءMapperهای سفارشی
🔹 ءSerializerهایی که روی Fieldها کار می‌کنند
🔹 ءUnit Testهایی که به نام Field وابسته‌اند

💡 نکته مهم

استفاده از field فقط یک Refactor ظاهری نیست.
اگر زیرساخت پروژه به نام Backing Field وابسته باشد، در واقع دارید Contract داخلی برنامه را تغییر می‌دهید.
و این دسته از خطاها معمولاً نه توسط کامپایلر شناسایی می‌شوند و نه توسط بسیاری از Unit Testها؛ بلکه اولین بار در محیط Production خودشان را نشان می‌دهند.

🎯 جمع‌بندی

قابلیت field در C# 14 یکی از بهترین امکانات جدید زبان است و باعث کاهش Boilerplate و خواناتر شدن کد می‌شود.
اما قبل از مهاجرت، مطمئن شوید پروژه شما به نام Backing Fieldها وابسته نیست؛ در غیر این صورت، یک Refactor ساده می‌تواند به خطاهای Runtime، شکست Mappingهای EF Core و مشکلات Reflection منجر شود.

🔗Source

🔖 هشتگ‌ها:
#dotnet #csharp14 #EFCore #Reflection #Runtime #DotNetTips