C# 15’te Union Types: Eksik Parça Nihayet Geldi
C# tarafında yıllardır eksik duran bir parça vardı… işin aslı şu ki, çoğu geliştirici bunu başka dillerde görüp “keşke bizde de olsa” diyordu. C# 15 ile gelen union anahtar sözcüğü tam da o boşluğu dolduruyor. Ben ilk kez F# tarafında discriminated union mantığını kurcaladığımda, “Bu kadar net ve güvenli bir model niye C#’ta yok?” diye bayağı söylenmiştim. Şimdi tablo değişiyor.
Açık konuşayım, bu özellik sadece “güzel bir dil eklentisi” değil. Kurumsal tarafta, özellikle hata yönetimi, sonuç tipi modelleme. Farklı nesne türlerini tek bir kontratta toplama işlerinde bayağı iş görüyor — bence çok yerinde bir karar —. Geçen yıl Şubat 2025’te bir finans müşterisinde API dönüşlerini sadeleştirirken aynı sorunu yaşamıştık: ya object kullanıp belirsizliğe teslim olacaktık ya da gereksiz kalıtım zincirleri kuracaktık (ki bu çoğu kişinin gözünden kaçıyor). İkisi de idare eder gibi görünüyordu ama pratikte çamur gibiydi.
Neden bu kadar geç kaldı?
Küçük bir detay: Aslında dur, önce şunu söyleyeyim: C# zaten pattern matching konusunda güçlüydü. Ama güçlü olması, her problemi çözdüğü anlamına gelmiyor. object kullandığınızda compiler size pek yardım etmiyor; marker interface veya abstract base class kullandığınızda işe kapalı bir küme elde edemiyorsunuz. Yanı derleyici “tamam kardeşim, bu iş burada bitti” demiyor.
Ben bunu en net 2019’da kendi lab ortamımda görmüştüm. Küçük bir envanter servisinde ErrorOrValue benzeri yapı kurmaya çalışıyorduk. İlk başta basit geldi. Sonra iki yeni hata tipi eklendi, ardından üçüncü ekip kendi exception sınıfını dayattı… derken sistem genişledi ama kontrol kayboldu. İşte union types’ın olayı tam burada başlıyor: tip seti kapanıyor ve compiler bunu biliyor.
Ha bu arada, F# bilenler için sürpriz yok; onlar buna zaten alışık. Ama C#’ın sunduğu deneyim daha “native”. Mevcut pattern matching bilgisini çöpe atmıyorsun, üstüne yeni bir katman ekliyorsun. Bu bence önemli çünkü ekiplerde herkes F# bilmiyor ama C# bilen çok var.
| Yaklaşım | Avantaj | Sorun |
|---|---|---|
object |
Baskısız, hızlı başlar | Tip güvenliği zayıf |
| İnterface / base class | Daha düzenli görünür | Kümeyi kapatamazsın |
union |
Kapatılmış tip seti + exhaustive match | .NET 11 ön izleme dönemi olduğu için erken aşama riskleri var |
Kod nasıl görünüyor?
Sade örnekle gidelim. Mesela evcil hayvanları modellemek istiyorsunuz:
Durun, bir saniye.
public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);
public union Pet(Cat, Dog, Bird);
Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value);
string name = pet switch
{
Dog d => d.Name,
Cat c => c.Name,
Bird b => b.Name,
};Şahsen, Bunun hoş tarafı şu: Pet, rastgele her şeyi tutmuyor; yalnızca belirlediğiniz üç tipi tutuyor. Compiler da bunu biliyor ve switch yazarken sizden eksiksiz eşleşme bekliyor. Kısacası “default koyayım da kurtulayım” devri biraz geride kalıyor.
Aslında, Lafı gevelemeden söyleyeyim: bu yapı özellikle domain-driven design tarafında elinizi rahatlatır. Mesela ödeme akışında CardPaymentResult, BankTransferResult, PaparaResult? gibi farklı case’leri tek yerde toplamak mümkün olurken saçma sapan inheritance ağacı kurmak zorunda kalmazsınız.
Küçük startup için ne ifade ediyor?
Küçük ekiplerde hız önemli ama hızın bedeli çoğu zaman teknik borç oluyor. Startuplarda genelde ilk hafta herkes mutlu; üçüncü ayda işe kimse kimin ne döndürdüğünü bilmiyor. Union types burada kodu sıkılaştırıyor ama fazla ritüel de istemiyor.
Eğer 4-5 kişilik bir ürün ekibiniz varsa ve backend’i.NET ile yazıyorsanız, bu özellik sizi özellikle API response modellerinde toparlar. Bir arkadaşım Kasım 2024’te İzmir’de küçük bir SaaS girişiminde benzer modeli manuel olarak taklit etmişti; iki sprint sonra ekip “neden bunu derleyiciye bırakmadık ki?” diye pişman olmuştu… haklılardı.
Enterprise seviyede neden daha kıymetli?
İtiraf edeyim, Büyük organizasyonlarda mesele sadece doğruluk değil; bakım maliyeti de var (ciddiyim). AZ-305 sınavına hazırlanırken bile hep aynı şeyi düşünürdüm: mimarı kararların uzun vadeli etkisi kısa vadeli kazançtan daha önemli. Union type burada tam o çizgide dürüyor.
Bir dakika — bununla bitmedi.
Union types’ın asıl gücü “çok şey yapması” değil; yanlış şeyi yaptırmaması.
Derleyicinin sizi dürtmesi bazen sınır bozucu olur…
ama prod ortamında gece uykusunu kurtaran şey de tam olarak budur.
Nerede parlıyor, nerede biraz ham kalıyor?
Bayağı iyi olduğu yerler belli: result modeling, validation flow’lar, parse edilmiş veri ayrıştırma işleri. Birbirine alakasız türleri tek sözleşmede toplamak istediğiniz anlar. Mesela de de null kontrolünü düzgün yapmak isteyen ekiplerde güzel oturur.
Aslında, Ama beklentiyi abartmayalım. Kağıt üstünde iyi görünen her özellik gibi bunun da erken dönem gölgeleri olabilir..NET 11 Preview 2 ile geldiği için bazı araç zincirlerinin henüz neredeyse tamamen oturmamış olması normaldir (mesela IDE davranışları veya analizörler). Yanı evet, yenilik fena değil… İlginç, değil mi? fakat üretime koşmadan önce birkaç tür test etmek şart.
- Daha temiz kontrat: Hangi tiplerin mümkün olduğu açıkça belli olur.
- Daha iyi exhaustive check: Derleyici eksik case’leri yakalar.
- Daha az inheritance baskısı: Kalıtım zinciri kurmak gerekmez.
- Dikkat: Erken aşama risklerini göz önünde bulundurun.
Sahada nasıl yaklaşırım?
Açık konuşayım, ben böyle özellikleri hemen “her yere yayalım” kafasında almıyorum. Önce dar bir kullanım alanı seçerim; mesela sadece API response modelleri ya da command result sınıfları gibi yerlerde denerim. Logosoft’ta geçen sene yaptığımız bir Azure entegrasyonunda da böyle ilerledik: önce küçük yüzey alanı seçtik, sonra yaygınlaştırdık.
E tabiî büyük şirketlerde mesele sadece kod yazmak değil; governance var, code review var, eğitim var… O yüzden union type geldi diye mevcut pek çok abstract class yapılarını silmek doğru olmaz. Hatta bazı yerlerde eski yaklaşım hâlâ daha okunaklı olabilir.
Neyse uzatmayalım: benim tavsiyem şu — eğer domain’inizde gerçekten “yalnızca şu üç-dört seçenek geçerli” diyebiliyorsanız union types’a bakın! Yok eğer tip sayısı sürekli artıyorsa ya da dış sistemler sözleşmeyi sürekli zorluyorsa önce tasarımı düzeltin; özellik tek başına mucize yaratmaz.
Kullanırken dikkat edeceğim noktalar neler?
- Kapalılık gerçekten gerekli mi?
- Ekip anlayacak mı?
- Teslim zinciri hazır mı?
- null senaryoları net mi?
Bence burada en kritik konu sadelikle disiplin arasındaki dengeyi tutturmak. Sadece modern görünmek için kullanırsanız ters teper; ama doğru yerde kullanırsanız bayağı temiz sonuç veriyor.
Şimdi gelelim pratik okumaya…
Sıkça Sorulan Sorular
C# 15 union types nedir?
C# 15’te gelen union, bir değişkenin önceden tanımlanmış birkaç tipten yalnızca biri olmasını sağlar. Derleyici de bu setin dışına çıkılmasına izin vermez.
switch ifadelerinde neden önemli?
Eksen noktası burada exhaustive pattern matching oluyor. Yanı tüm case’leri kapsadığınızdan emin olunuyor (buna dikkat edin). Default branch’e ihtiyaç azalıyor.
Mevcut abstract class yerine kullanılabilir mi?
Bazı senaryolarda evet, ama hepsinde değil. Eğer ortak davranıştan çok kapalı tip kümesi önemliyse union daha doğru seçim olur.
.NET uygulamalarında nerede başlamak mantıklı?
Bir şey dikkatimi çekti:
Küçük başlayın: API response, validation result, domain event sonucu gibi alanlar iyi adaydır. Büyük refactor yerine kontrollü pilot öneririm.
Kaynaklar ve İleri Okuma
C# 15 ile Union Types duyurusu — Microsoft.NET Bloğu
C# resmî dokümantasyonu — Microsoft Learn
Pattern Matching rehberi — Microsoft Learn
Microsoft Agent Framework 1.0: Ajanlar Artık Ciddileşti
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
