کلمه کلیدی field در C# 14
کلمهکلیدی **field** یکی از فیچرهای جدید **C# 14** (و .NET 10) است که به شما اجازه میدهد بدون تعریف صریح backing field، در accessor پراپرتی به فیلد پشتیبان دسترسی داشته باشید. در این مقاله با **مثال واقعی**، **مزایا و معایب**، **مقایسه با backing field دستی** و **تجربه عملی یک senior developer** آشنا میشوید.
وقتی تمیزی کد با کنترل واقعی برخورد میکند.
سلام، محمد محسنی هستم.
هفتهٔ پیش که NET 10 RC2. رو نصب کردم، اولین چیزی که رفتم سراغش field keyword بود. راستش خیلی هیجان داشتم؛ بالاخره دیگه لازم نبود برای هر پراپرتی که یه validation ساده داشت، یه فیلد something_ جدا بنویسم.
دو روز کامل کد زدم، تست نوشتم، warning گرفتم، warning رو سرکوب کردم، دوباره warning گرفتم… و آخرش برگشتم همون something_ قدیمی خودم رو نگه داشتم. این مقاله همون داستان واقعی همون دو روزه.
اول یه مثال واقعی بزنیم
فرض کن داریم یه User میسازیم که ایمیلش هیچوقت null یا خالی نباشه و حتماً @ داشته باشه.
روش کلاسیک (همونی که من هنوز استفاده میکنم)
public class User
{
private string _email = string.Empty;
public string Email
{
get => _email;
init => _email = Validate(value);
private static string Validate(string? value)
{
if (string.IsNullOrWhiteSpace(value) || !value.Contains('@', StringComparison.Ordinal))
throw new ArgumentException("ایمیل معتبر نیست.");
return value.Trim();
}
}
}روش جدید C# 14
public class User
{
public string Email
{
get;
init => field = !string.IsNullOrWhiteSpace(value) && value.Contains('@')
? value.Trim()
: throw new ArgumentException("ایمیل معتبر نیست.");
}
}خب، کد دوم ۶ خط کمتره. خیلی تمیزتره. چرا من هنوز اولی رو ترجیح میدم؟
چهار دلیلی که باعث شد برگردم به backing field دستی
۱. دیباگ کردن
وقتی breakpoint میزنم، من email_ رو میبینم. میتونم Watch بزنم، Edit & Continue کنم، ببینم کی مقدارش عوض شده. با field keyword فقط پراپرتی رو میبینم؛ فیلدش مخفیه. تو پروژههای بزرگ این موضوع خیلی دردسرساز میشه.
۲. Lazy initialization و caching
فرض کن یه ConnectionString داری که فقط وقتی اولین بار لازم شد از vault بخونی. با backing field دستی یه خط کافیه:
private string? _connectionString;
public string ConnectionString => _connectionString ??= Vault.ReadAsync("db").GetAwaiter().GetResult();با field keyword همچین کاری نمیتونی بکنی؛ چون فقط توی accessor دسترسی داری.
۳. EF Core و Serializerها
من چندین بار دیدم که JsonSerializer یا EF Core با پراپرتیهای field-backed مشکل داشته باشن (مخصوصاً وقتی [JsonInclude] یا [BackingField] میخوای). با فیلد دستی همهچیز predictable هست.
۴. تیم چندین نفره
وقتی هنوز فقط نیمی از تیم با C# 10 کار میکنن، وقتی یکی میبینه field = value نوشته شده، اول میپرسه «این field چیه؟» وقتی email_ میبینه، همه میدونن یعنی چی.
پس کی از field استفاده کنیم؟
من خودم در شرایط زیر استفاده از field keyword رو پیشنهاد میدم:
- پروژههای شخصی
- کتابخانههای کوچک که فقط یک نفر توسعه دهنده اون هست
- دمو و آموزش
- Prototype و Spike
اما تو پروژهٔ اصلی شرکت که تعداد زیادی میکروسرویس داره و تعدا زیادی developer روش کار میکنن؟ نه. هنوز هم custom backing field رو نگه میدارم.
جمعبندی
field keyword یه فیچر قشنگ و تمیزه. ولی تمیزی همیشه به معنی بهتر نیست. من تو production هنوز ترجیح میدم کنترل کامل دست خودم باشه.
شما چی؟ تو پروژهتون از field استفاده کردید یا هنوز هم something_ مینویسید؟ تو کامنت بگید، خیلی مشتاقم بدونم.
نویسنده: محمد محسنی | برنامه نویس ارشد Net.
آخرین بروزرسانی: ۸ نوامبر ۲۰۲۵ | 1404/08/17