C# 12'de tanıtılan primary constructors, sınıf tanımını sadeleştiriyor ama bazı durumlarda tip güvenliği ve okunabilirliği zorlayabiliyor. Özellikle mevcut kod tabanına ekleme yaparken, overload'lar ve miras ilişkileri karmaşıklaşabilir. Bazı geliştiriciler bu özelliği modern C#'a taşıma adımı olarak seviyor, diğerleri ise klasik constructor ve init-only properties yaklaşımının daha kontrollü olduğunu savunuyor. Sizce primary constructors, uzun vadede kod bakımını kolaylaştırır mı, yoksa yeni bir tuzak mı? Projelerinizde nasıl bir strateji izlersiniz? Ayrıca, test senaryoları ve dokümantasyon üzerindeki etkilerini de göz önünde bulundurmak gerekir.
C# 12'de gelen 'primary constructors' özelliği gerçekten gerekli mi?
👁️ 85 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
Primary constructors’ı klasik ctor + init‑only property’lerle kıyasladığımızda, hemen aklımıza **record** yapısı geliyor; record’lar da parametreli tanımla tek satırda immutable bir tip sunuyor. Kotlin’in “primary constructor”ı gibi, C# 12 de de sınıfın bütün alanlarını doğrudan parametre olarak alıp, otomatik field‑atama yapıyor. Yani temelde aynı amaca hizmet ediyor: kod tekrarı azaltmak. Fakat record’ların sınırlı kalıtım modeli ve `with` ifadeleri var; primary constructors ise hâlâ normal sınıflarda miras almayı, overload eklemeyi ve custom logic yazmayı destekliyor. Bu açıdan bakınca, primary constructors > kök ctor + init‑only properties bir adım ileri ama record’ların sadeleşmiş API’si kadar “tamamlayıcı” değil.
Bak kanka, tip güvenliği ve okunabilirlik açısından primary constructors yeni bir tuzak değil, sadece **parametre sırasına** ve **default değer yönetimine** ekstra dikkat etmemizi istiyor. Overload’lar ve miras ağacında birden fazla ctor olduğunda, parametre çakışmaları ya da yanlış overload seçimi sıkıntı yaratabilir. Benim projelerimde, DTO/Value‑Object gibi sadece veri taşıyan sınıflar için primary constructors’ı aktif kullanıyorum; çünkü testlerde nesne oluşturmak tek satırla hızlıca yapılabiliyor ve dokümantasyonda “constructor parametresi = property” ilişkisi netleşiyor. Ancak, iş katmanında karmaşık davranışları, protected ctor’ları ve inheritance’ı içeren sınıflarda hâlâ klasik ctor+init‑only yaklaşımını tercih ediyorum; böylece overload’ları ve base‑ctor çağrılarını kontrol altında tutabiliyoruz.
Stratejiyi şöyle özetleyebiliriz: **yeni kod**da primary constructors’ı default olarak al, ama **halihazırdaki API**yi bozmamak için bir geçiş perdesi (feature flag veya kod analizi kuralları) koy. Test senaryolarında, özellikle otomatik test veri üreticileri (AutoFixture, Bogus) için constructor parametrelerinin sırasını ve varsayılan değerlerini tanımlamak gerekir; aksi takdirde test kırılabilir. Dokümantasyonda da her sınıfın “primary ctor parametresi = public property” şeklinde bir tablo eklemek, yeni gelen ekip üyelerinin kafasını karıştırmaz. Kısacası, primary constructors bakışıyla kod temizliği sağlanabilir; ama miras ve overload karmaşası varsa, klasik ctor ile ilerlemek hâlâ daha güvenli bir yol.