Dize türünün varsayılan değeri neden boş bir dize yerine null?

Bunun için bütün dizeleri test etmek oldukça can sıkıcı nullgüvenle gibi yöntemleri uygulamadan önce ToUpper(), StartWith()vs ...

Varsayılan değeri stringboş dize olsaydı, sınamak zorunda kalmazdım ve örneğin intveya gibi diğer değer türleriyle daha tutarlı olmasını hissederdim double. Ayrıca Nullable<String>mantıklı olurdu.

Peki neden C # tasarımcıları nulldizelerin varsayılan değeri olarak kullanmayı seçtiler?

Not: Bu, bu soru ile ilgilidir , ancak bununla ne yapmak yerine neden daha çok odaklanmaktadır.

Dize türünün varsayılan değeri neden boş bir dize yerine null?

Çünkü stringbir referans türüdür ve tüm referans tipleri için varsayılan değerdir null.

ToUpper (), StartWith () vb.Gibi yöntemleri güvenle uygulayabilmek için tüm dizelerimi null için test etmek oldukça can sıkıcı bir durum.

Bu, referans türlerinin davranışıyla tutarlıdır. Örnek üyelerini çağırmadan önce, boş bir başvuru için onay alınmalıdır.

Dize'nin varsayılan değeri boş dize olsaydı, sınamak zorunda kalmazdım ve örneğin int veya double gibi diğer değer türleriyle daha tutarlı olmasını hissederdim.

Varsayılan değeri başka bir referans türüne atamak, değeri tutarsıznull hale getirir .

Ayrıca Nullable<String>mantıklı olurdu.

Nullable<T>değer türleriyle çalışır. Dikkat çekici bir gerçektir Nullableorijinal üzerinde tanıtılan değildi .NET platformunun kırık kod çok onlar o kuralı değişmişti olurdu böylece. ( İzniyle @jcolebrand )

Habib haklı - çünkü stringbir referans türü.

Ancak daha da önemlisi, her kullandığınızda kontrol etmeniz gerekmeznull . ArgumentNullExceptionBirisi işlevinizi bir nullreferans geçerse, muhtemelen bir atmalısınız .

İşte bir şey - bir dize NullReferenceExceptionçağırmaya çalışırsanız çerçeve yine de sizin için bir atar .ToUpper(). nullParametrelerin değerlendirebileceği gibi işlevinize iletilen nesneler üzerindeki herhangi bir özellik veya yöntem için argümanlarınızı test etseniz bile bu durumun hala olabileceğini unutmayın null.

Varlık dedi ki, boş dizeleri veya boş değerlere kontrol yapmak için bir ortak şey, sağladıkları bu yüzden String.IsNullOrEmpty()ve String.IsNullOrWhiteSpace()sadece bu amaç için.

Bir uzantı yöntemi yazabilirsiniz (değeri için):

public static string EmptyNull(this string str)
{
    return str ?? "";
}

Şimdi bu güvenli bir şekilde çalışıyor:

string str = null;
string upper = str.EmptyNull().ToUpper();

C # 6.0 itibarıyla aşağıdakileri de kullanabilirsiniz

string myString = null;
string result = myString?.ToUpper();

Dize sonucu boş olacaktır.

Boş dizeler ve boş değerler temelde farklıdır. Boş, bir değerin olmaması ve boş bir dize, boş olan bir değerdir.

Bu durumda boş bir dize olan bir değişkenin "değeri" hakkında varsayımlar yapan programlama dili, dizeyi boş bir başvuru sorununa neden olmayacak başka bir değerle başlatmak kadar iyi olacaktır.

Ayrıca, tanıtıcıyı bu dize değişkenine uygulamanın diğer bölümlerine iletirseniz, bu kodun bilerek boş bir değer geçirip geçirmediğinizi veya bu değişkenin değerini doldurmayı unuttuğunuzu doğrulamanın hiçbir yolu olmaz.

Bunun bir sorun olacağı başka bir durum, dizenin bazı işlevlerden bir dönüş değeri olmasıdır. Dize bir başvuru türü olduğundan ve teknik olarak her ikisi de boş ve boş olarak bir değere sahip olabileceğinden, işlev aynı zamanda teknik olarak bir boş veya boş döndürebilir (bunu durdurmak için hiçbir şey yoktur). Şimdi, "bir değerin yokluğu", yani boş bir dize ve bir boş olmak üzere 2 kavram olduğundan, bu işlevi tüketen tüm kodun 2 kontrol yapması gerekecektir. Biri boş, diğeri boş.

Kısacası, tek bir devlet için sadece 1 temsile sahip olmak her zaman iyidir. Boş ve boş değerlerle ilgili daha geniş bir tartışma için aşağıdaki bağlantılara bakın.

/software/32578/sql-empty-string-vs-null-value

Kullanıcı girişi ile uğraşırken NULL vs Empty

Temel neden / sorun, CLS spesifikasyonunun tasarımcılarının (dillerin .net ile nasıl etkileşime girdiğini tanımlayan) sınıf üyelerinin callvirt, arayan bir null-referans kontrolü; ne de "normal" bokslamaya tabi olmayacak yapıların tanımlanması için bir ortalama sağlamadı.

CLS spesifikasyonu böyle bir araç tanımlamış olsaydı, o zaman .net'in Ortak Nesne Modeli (COM) tarafından kurulan ve altında boş bir dize başvurusunun semantik olarak boş bir dizeye eşdeğer olduğu kabul edilen lead'i tutarlı bir şekilde izlemesi mümkün olurdu. varsayılan değerleri tanımlamak için değer semantiğine sahip olması gereken kullanıcı tanımlı değişmez sınıf türleri. Esasen, her bir üye için ne olacağını String, örneğin bir Lengthşey gibi yazılacaktı [InvokableOnNull()] int String Length { get { if (this==null) return 0; else return _Length;} }. Bu yaklaşım, değer gibi davranması gereken şeyler için çok güzel bir anlambilim sunacaktır, ancak uygulama sorunlarının yığın üzerinde depolanması gerekir. Bu yaklaşımla ilgili en büyük zorluk, bu türler arasındaki dönüşüm semantiğinin ve Objectbiraz bulanık olabilmesidir.

Alternatif bir yaklaşım, miras almayan, Objectbunun yerine özel boks ve kutudan çıkarma operasyonlarına sahip olan (diğer bazı sınıf tiplerine dönüşebilen) özel yapı tiplerinin tanımlanmasına izin vermek olurdu. Böyle bir yaklaşıma göre, bir sınıf tipi olacağını NullableStringdize şimdi yaptığı gibi davranır ve özel kutulu yapı tipi Stringtek özel alan yapacağını, ValueÇeşidi String. Bir dönüştürmek için çalışılıyor Stringetmek NullableStringveya Objectdönecekti Valueolmayan boş ise, ya String.Emptyboş eğer. Yayınlamaya çalışıldığında String, bir NullableStringörneğe null olmayan bir başvuru başvuruyu depolar Value(belki de uzunluk sıfırsa null değerini saklar); başka bir atıfta bulunmak istisna oluşturur.

Dizelerin yığın üzerinde depolanması gerekmesine rağmen, kavramsal olarak null olmayan varsayılan değere sahip değer türleri gibi davranmamaları için hiçbir neden yoktur . Bir referansı tutan "normal" bir yapı olarak saklanmaları, bunları "dize" türü olarak kullanan kod için etkili olurdu, ancak "nesneye" döküm yaparken fazladan bir dolaylama ve verimsizlik katmanı ekleyecektir. .Net bu geç tarihte yukarıdaki özelliklerden birini eklemeyi öngörmese de, belki de gelecekteki çerçevelerin tasarımcıları bunları dahil etmeyi düşünebilir.

Çünkü bir dize değişkeni bir örnek değil , bir referanstır .

Varsayılan olarak Boş olarak başlatılması mümkün olurdu, ancak tüm tahtada çok fazla tutarsızlık ortaya çıkarırdı.

Neden C # tasarımcıları varsayılan dize değeri olarak null kullanmayı seçtiler?

Dizeler başvuru türleri olduğundan , başvuru türleri varsayılan değerdir null. Referans türlerinin değişkenleri, gerçek verilere referansları saklar.

defaultBu durum için anahtar kelime kullanalım ;

string str = default(string); 

stra string, bu nedenle bir referans türüdür , bu nedenle varsayılan değer 'dir null.

int str = (default)(int);

strbir olan intbir yüzden, değer türü varsayılan değerdir yüzden zero.

Varsayılan değeri stringboş dize olsaydı, test etmek zorunda kalmazdım

Yanlış! Varsayılan değerin değiştirilmesi, bunun bir referans türü olduğu gerçeğini değiştirmez ve birisi yine de başvuruyu açık olarak ayarlayabilirnull .

Ayrıca Nullable<String>mantıklı olurdu.

Gerçek nokta. nullHerhangi bir referans türüne izin vermemek , Nullable<TheRefType>bu özelliğe ihtiyaç duymak daha mantıklı olacaktır .

Peki neden C # tasarımcıları nulldizelerin varsayılan değeri olarak kullanmayı seçtiler?

Diğer referans türleriyle tutarlılık. Şimdi, neden nullreferans türlerine izin veriyorsunuz ? Muhtemelen C gibi hissettirir, ancak bu da bir dilde tartışmalı bir tasarım kararı olsa da Nullable.

Belki de ??string değişkeninizi atarken operatörü kullanırsanız, bu size yardımcı olabilir.

string str = SomeMethodThatReturnsaString() ?? "";
// if SomeMethodThatReturnsaString() returns a null value, "" is assigned to str.

Dize değişmez bir nesnedir, yani bir değer verildiğinde, eski değer bellekten silinmez, ancak eski konumda kalır ve yeni değer yeni bir konuma yerleştirilir. Varsayılan değeri Yani eğer String aoldu String.Empty, ziyan olur String.Emptyonun ilk değeri verildiğinde bellekte bloğu.

Küçük gibi görünse de, varsayılan değerleri olan büyük bir dizi diziyi başlatırken soruna dönüşebilir String.Empty. Tabii ki, StringBuildereğer bu bir problem olacaksa , değişebilir sınıfı her zaman kullanabilirsiniz .

Dize bir başvuru türü olduğundan ve başvuru türü için varsayılan değer boştur.

Belki stringde diğerleri gibi tam göründüğü anahtar kelime, karıştırdım değer türü bildiriminde, ama aslında bir takma olduğu System.Stringaçıklandığı gibi bu soruya .
Ayrıca Visual Studio'daki koyu mavi renk ve küçük harfli ilk harfin yanlış olduğunu düşünebilir struct.

Null olabilecek türler 2.0'a kadar gelmedi.

Null olabilecek türler dilin başında yapılmış olsaydı, dize null edilemez ve dize olur mu? geçersiz olacaktır. Ancak geriye dönük uyumluluk için bunu yapamadılar.

Birçok insan ref-tipi veya ref tipi hakkında konuşmaz, ancak dize sıradan sınıfın dışındadır ve bunu mümkün kılmak için çözümler bulunmuş olurdu.