Programlama dillerinde boş referansların bulunmasının "milyar dolarlık hata" olduğunu söylemiştim. Ama neden? Tabii, NullReferenceExceptions'e neden olabilirler, peki ne olmuş? Dilin herhangi bir unsuru, eğer yanlış kullanılırsa bir hata kaynağı olabilir.

Ve alternatif nedir? Sanırım bunu söylemek yerine:

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

Bunu söyleyebilirsin:

if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); 
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

Ama bu nasıl daha iyi? Her iki durumda da, müşterinin varlığını kontrol etmeyi unutursanız, bir istisna elde edersiniz.

Bir CustomerNotFoundException'ın daha açıklayıcı olması nedeniyle NullReferenceException'dan hata ayıklamaktan biraz daha kolay olduğunu düşünüyorum. Hepsi bu kadar mı?

null kötüdür

: Bu konu hakkında InfoQ bir sunum yoktur boş Referanslar: Milyar Dolar Hata tarafından Tony Hoare

Seçenek tipi

Fonksiyonel programlamanın alternatifi, ya da içerebilen bir Seçenek tipi kullanmaktır .SOME valueNONE

İyi bir makale Seçenek türünü tartışan ve bunun Java için uygulanmasını sağlayan “Seçenek” Deseni .

Ayrıca, bu konuda Java için bir hata raporu buldum: NullPointerExceptions özelliğini önlemek için Java'ya Güzel Seçenek türleri ekleyin . İstenen özellik Java 8'de tanıtıldı.

Sorun, teoride herhangi bir nesnenin boş olabileceği ve onu kullanmaya çalıştığınızda bir istisna atabileceği için, nesne yönelimli kodunuzun temelde patlamamış bombalar topluluğu olmasıdır.

Zarif hata işlemenin işlevsel olarak boş denetleme ififadeleriyle aynı olabileceği konusunda haklısınız . Fakat kendinizi ikna ettiğiniz bir şey muhtemelen boş olamazsa ne olur ? Kerboom. Sonra ne olursa olsun, bahse girerim ki 1) zarif olmayacak ve 2) hoşuna gitmeyecek.

Ve "hata ayıklaması kolay" değerini reddetmeyin. Olgun üretim kodu çılgınca, yayılan bir yaratıktır; neyin yanlış gittiği ve sizi saatlerce kazıdan kurtaracak yer hakkında daha fazla bilgi veren herhangi bir şey.

Kodda boş referanslar kullanmanın çeşitli problemleri vardır.

İlk olarak, genellikle özel bir durumu belirtmek için kullanılır . Uzmanlıklar normal olarak yapılırken her bir durum için yeni bir sınıf veya sabit tanımlamak yerine, boş bir referans kullanarak, kayıplı, kitlesel bir genelleştirilmiş tip / değer kullanılır .

İkincisi, null bir başvuru göründüğünde hata ayıklama kodu daha zor hale gelir ve neyi oluşturduğunu , hangi durumun geçerli olduğunu ve nedenini yukarı yöndeki yürütme yolunu izleyebilseniz bile nedenini belirlemeye çalıştığınızda zorlaşır .

Üçüncü olarak, boş referanslar test etmek için ek kod yolları sunar .

Dördüncüsü, boş referanslar parametrelerin yanı sıra dönüş değerleri için geçerli durumlar olarak kullanıldığında, savunma programlaması (tasarımın neden olduğu durumlar için) , çeşitli durumlarda yapılacak daha boş referans kontrolü gerektirir …

Beşinci olarak, dilin çalışma zamanı zaten bir nesnenin yöntem tablosunda seçici arama gerçekleştirdiğinde tür denetimleri gerçekleştiriyor. Dolayısıyla, nesnenin türünün geçerli / geçersiz olup olmadığını kontrol ederek ve ardından çalışma zamanının yöntemini çağırmak için geçerli nesnenin türünü kontrol etmesini sağlayarak çabaları çoğaltırsınız.

Neden kullanmayın NullObject deseni için çalışma zamanının kontrol yararlanmak bunu çağırmak için NOP sizin kod temeli boyunca da boş referanslar için tüm ekstra denetimi ortadan kaldırırken o halde (normal devletin arabirimine uygun) özel yöntemler?

Bu daha çok işe neden özel bir durumu temsil istediğiniz her arayüz için bir NullObject sınıfını oluşturarak. Ancak en azından uzmanlık, devletin var olabileceği koddan ziyade her bir özel duruma izole edilir. Şimdi, yöntemlerinde daha az alternatif yürütme yoluna sahip olduğunuz için test sayısı azalır .

Null'lar o kadar da kötü değil, beklemiyorsanız. Sen gerektiğini açıkça dile tasarım sorunudur null bekliyorsanız kodu belirtmek gerekir. Bunu düşün:

Customer? c = Customer.GetByLastName("Goodman");
// note the question mark -- 'c' is either a Customer or null
if (c != null)
{
    // c is not null, therefore its type in this block is
    // now 'Customer' instead of 'Customer?'
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

A yöntemlerini çağırmaya çalışırsanız Customer?, derleme zamanı hatası almalısınız. Daha fazla dilin bunu yapmamasının nedeni (IMO), hangi kapsamda olduğuna bağlı olarak değişmek üzere bir değişkenin türünü sağlamamış olmalarıdır. tip sistemi

Opsiyon tiplerini kullanarak bu problemi çözmenin fonksiyonel bir yolu da var Maybe, ama ben o kadar aşina değilim. Bu yolu tercih ederim, çünkü doğru kod teorik olarak doğru bir şekilde derlemek için sadece bir karaktere ihtiyaç duymalıdır.

Talihsiz semptomlarını kapsayan birçok mükemmel cevap var null, bu yüzden alternatif bir argüman sunmak istiyorum: Null, tip sistemindeki bir kusurdur.

Bir tip sistemin amacı, bir programın farklı bileşenlerinin "birbirine tam olarak uyması"; iyi yazılmış bir program tanımsız davranışa “raylardan” kaçamaz.

Varsayımsal bir Java lehçesi düşünün ya da tercih ettiğiniz statik olarak yazılmış dil ne olursa olsun, dizeyi "Hello, world!"herhangi bir değişkene atayabilirsiniz :

Foo foo1 = new Foo();  // Legal
Foo foo2 = "Hello, world!"; // Also legal
Foo foo3 = "Bonjour!"; // Not legal - only "Hello, world!" is allowed

Ve bunun gibi değişkenleri de kontrol edebilirsiniz:

if (foo1 != "Hello, world!") {
    bar(foo1);
} else {
    baz();
}

Bunun imkansız bir tarafı yok - isterlerse biri böyle bir dil tasarlayabilir. Özel değerin olması gerekmez "Hello, world!"- 42 sayısı, sayı (1, 4, 9)ya da diyelim ki null. Ama bunu neden yaptın? Bir tür değişkeni Foosadece Foos tutacaktır - bu, tip sisteminin bütün noktası budur! nullolduğundan Foodaha fazla değil "Hello, world!". Daha da kötüsü, hiçbir türden nullbir değer değildir ve bununla yapabileceğiniz hiçbir şey yoktur!

Programcı bir değişkenin gerçekte bir a değerine sahip olduğundan asla emin Fooolamaz ve programın da yapamaz; tanımsız davranışlardan kaçınmak için değişkenleri s "Hello, world!"olarak kullanmadan önce kontrol etmek zorundadır Foo. Önceki kod parçasında dize denetimi yapmanın, foo1'in gerçekten bir Foo- olduğu gerçeğini yaymadığını - barbüyük olasılıkla kendi güvenliğini sağlamak için muhtemelen kendi denetimine sahip olacağını unutmayın.

Bunu, kalıp eşleştirme ile bir Maybe/ Optiontype kullanarak karşılaştırın :

case maybeFoo of
 |  Just foo => bar(foo)
 |  Nothing => baz()

İçinde Just foomaddesi, sen ve programın hem Emin bizim bu Maybe Foodeğişken gerçekten bir içermiyor Foodeğeri - bu bilgiler çağrı zincirini aşağı yayılır ve barherhangi denetimlerini yapmak gerekmez. Maybe FooFarklı bir tür olduğundan , Fooiçerme olasılığını ele almak zorunda Nothingkalırsınız, böylece asla a tarafından kör göremezsiniz NullPointerException. Programınız hakkında çok daha kolay bir neden olabilir ve derleyici, türün tüm değişkenlerinin Foogerçekten Foos içerdiğini bilerek boş denetimlerden kaçınabilir . Herkes kazanır.

(Eski bir soru için şapkamı ringe fırlatmak;)

Null ile ilgili özel sorun statik yazmayı bozmasıdır.

Eğer varsa Thing t, derleyici arayabileceğimi garanti edebilir t.doSomething(). Eh, UNLESS tçalışma zamanında boş. Şimdi tüm bahisler kapalı. Derleyici tamam dedi, ama taslında daha sonra olmadığını biliyorum doSomething(). Öyleyse, yazıcının hatalarını yakalamak için derleyiciye güvenmek yerine, onları yakalamak için çalışma zamanına kadar beklemeliyim. Python'u da kullanabilirim!

Bu nedenle, bir anlamda null, beklenen sonuçları içeren, statik olarak yazılmış bir sisteme dinamik yazmayı sağlar.

Bu sıfıra veya negatif log'a vb. Göre olan fark, i = 0 olduğunda, hala bir int'dir. Derleyici türünü hala garanti edebilir. Sorun, mantığın bu değeri, mantığın izin vermeyeceği bir şekilde yanlış uygulamasıdır ... ama mantık bunu yaparsa, bu hemen hemen bir hatanın tanımıdır.

(Derleyici olabilir gibi ifadeler işaretleme gibi. BTW, bu sorunlardan bazılarını yakalamak i = 1 / 0derleme zamanında. Ama gerçekten derleyici bir işlev haline takip etmek ve parametreler tüm işlevin mantığı ile tutarlı olmasını sağlamak için bekleyemeyiz)

Pratik sorun, fazladan fazla iş yapmanız ve çalışma zamanında kendinizi korumak için boş kontroller eklemenizdir, peki ya bir tanesini unutursanız? Derleyici atamalarını engeller:

S = s = yeni Tamsayı (1234);

Öyleyse neden referansları kıracak bir değere (boş) atanmasına izin vermelidir s?

Kodunuzda "yazılmamış" referanslarla "değer yok" ifadesini karıştırarak, programcılara fazladan bir yük getirmiş olursunuz. Ve NullPointerExceptions gerçekleştiğinde, onları izlemek daha da zaman alabilir. Aksine "Bunu söylemek statik yazarak güvenmek yerine ise dil demek alırız beklenen şey bir referans" "Bu iyi olabilir beklenen şey bir başvuru."

Bir nullişaretçi bir araçtır

bir düşman değil. Onları doğru kullanmalısın.

Boş bir işaretçi hatasını bulma ve düzeltmeye kıyasla, tipik bir geçersiz işaretçi hatasını bulmanın ve gidermenin ne kadar zaman alacağını bir dakika düşünün . Bir işaretçiyi aleyhine kontrol etmek kolaydır null. Boş olmayan bir göstergenin geçerli verileri gösterip göstermediğini doğrulamak bir PITA'dır.

Hala ikna olmadıysanız, senaryoya çok miktarda okuyuculu ekleyin ve tekrar düşünün.

Hikayenin ahlaki: Çocukları suyla atma. Ve kazanın araçlarını suçlama. Sayıyı uzun zaman önce icat eden adam oldukça zekiydi, o günden beri "hiçbir şey" olarak adlandırabiliyordunuz. nullİşaretçi şimdiye kadar bunlardan uzak değildir.

EDIT: Her ne kadar NullObjectdesen boş olabilecek referanslardan daha iyi bir çözüm gibi görünse de, problemleri kendi kendine ortaya koymaktadır:

• Bir NullObjectyöntem tutan bir referans (teoriye göre) tutan bir şey çağrıldığında hiçbir şey yapmaz. Bu nedenle, artık boş olmayan (yehaa!) Olduğu garanti edilen, ancak istenmeyen bir eylem gerçekleştirdiği, hatalı şekilde atanmamış referanslar nedeniyle ince hatalar ortaya çıkabilir. Bir NPE ile sorunun nerede olduğu açıkça bellidir. Bunun bir NullObjectşekilde (ancak yanlış) davranmasıyla, geç fark edilen hataların da görülmesi riski vardır. Bu, kazara geçersiz bir işaretçi sorununa benzer değildir ve benzer sonuçları doğurur: Referans, geçerli veriler gibi görünen, ancak görünmeyen, veri hatalarına neden olan ve izlenmesi zor olabilen bir şeye işaret eder. Dürüst olmak gerekirse, bu durumlarda göz açıp kapayıncaya kadar hemen başarısız olan bir NPE'yi tercih ederim.birden bire bana yolun aşağısında çarptığım bir mantıksal / veri hatası üzerinden. IBM'in hataların maliyeti konusunda hangi aşamada tespit edildiğinin bir işlevi olduğunu hatırlayın?

• Bir yöntem çağrıldığında hiçbir şey yapmama kavramı, NullObjectbir özellik alıcısı veya bir işlev çağrıldığında veya yöntem, değerleri döndürdüğünde geçerli olmaz out. Diyelim ki, geri dönüş değeri birdir intve biz karar veriyoruz, "hiçbir şey yapmamak" ın "geri dönüş 0" anlamına geliyor. Ancak, 0'ın, döndürülecek (döndürülmemiş) doğru "hiçbir şey" olmadığından nasıl emin olabiliriz? Sonuçta, NullObjecthiçbir şey yapmamalı, ancak bir değer istendiğinde bir şekilde tepki vermesi gerekir. Başarısızlık bir seçenek değildir: NullObjectNPE'yi önlemek için onu kullanırız ve kesinlikle başka bir istisnaya karşı işlem yapmayız (uygulanmadı, sıfıra böl, ...), değil mi? Öyleyse, bir şeyi iade etmek zorunda kaldığında hiçbir şeyi doğru bir şekilde nasıl geri veremezsin?

Yardım edemem, ancak birileri NullObjecther bir problem için deseni uygulamaya çalıştığında, bir hatayı bir diğerini yaparak düzeltmeye çalışmak gibi görünüyor. Hiç şüphesiz bazı durumlarda iyi ve kullanışlı bir çözümdür , ancak kesinlikle tüm durumlar için sihirli mermi değildir.

Boş referanslar bir hatadır çünkü duyusal olmayan koda izin verirler:

foo = null
foo.bar()

Tip sisteminden yararlanıyorsanız, alternatifler var:

Maybe<Foo> foo = null
foo.bar() // error{Maybe<Foo> does not have any bar method}

Genel fikir, değişkeni bir kutuya koymaktır ve yapabileceğiniz tek şey, kutuyu açmaktır, tercihen Eiffel için önerilen derleyici yardımını sağlamaktır.

Haskell scratch ( Maybe) 'e sahiptir, C ++' da kaldıraç kullanabilirsiniz boost::optional<T>ancak hala tanımsız davranışlar alabilirsiniz ...

Ve alternatif nedir?

İsteğe bağlı türler ve örüntü eşleme. C # bilmediğimden, burada Scala # :-) adlı kurgusal bir dilde bir kod parçası

Customer.GetByLastName("Goodman")    // returns Option[Customer]
match
{
    case Some(customer) =>
    Console.WriteLine(customer.FirstName + " " + customer.LastName + " is awesome!");

    case None =>
    Console.WriteLine("There was no customer named Goodman.  How lame!");
}

Boşluklarla ilgili sorun, onların sizi savunmaya karşı savunmaya zorlamalarına izin veren dillerdir. Bunu sağlamak için çok çaba sarf etmek (savunma if-blokları kullanmaya çalışmaktan çok daha fazla)

1. Onları boş bırakmamalarını beklediğiniz nesneler gerçekten boş değildir ve
2. Savunma mekanizmalarının gerçekten de tüm potansiyel NPE'lerle etkin bir şekilde başa çıkması.

Yani, aslında, nulllar sahip olmak için pahalı bir şey olur.

Programlama dilinizin, programınızın başlamadan önce programın doğruluğunu kanıtlamaya çalıştığı sorun. Statik olarak yazılmış bir dilde doğru tiplere sahip olduğunuzu kanıtladınız. Null olmayan referansların varsayılanına (isteğe bağlı null referansları ile) geçerek, null'un geçtiği ve olmaması gereken birçok durumu ortadan kaldırabilirsiniz. Sorun, geri çevrilemez referansları kullanma konusundaki ekstra çabanın programın doğruluğu bakımından yararına olup olmadığıdır.

Sorun o kadar boş değil, pek çok modern dilde boş olmayan bir başvuru türü belirtemezsiniz.

Örneğin, kodunuz benziyor olabilir

public void MakeCake(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    egg.Crack();
    MixingBowl.Mix(egg, flour, milk);
    // etc
}

// inside Mixing bowl class
public void Mix(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    //... etc
}

Sınıf referansları etrafından geçtiğinde, savunma programlaması, tüm parametreleri önceden null için kontrol etseniz bile, özellikle test altında yeniden kullanılabilir birimler oluştururken bile, null için tüm parametreleri kontrol etmenizi teşvik eder. Aynı referans, kod temeli üzerinden 10 kez kolayca kontrol edilebilir!

Bir şey aldığınızda normal bir null türüne sahip olmanız, null ile o zaman ve oraya gitmeniz daha iyi olmaz mıydı? zaman?

Bu, Seçenek çözümünün amacı - hata durumlarını açmanıza izin vermek değil, boş argümanları tam olarak kabul edemeyen işlevlerin tasarımına izin vermek. "Varsayılan" türlerin uygulanmasının null veya null olmayan olması, her iki aracın da kullanılabilmesi esnekliğinden daha az önemlidir.

http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

Bu aynı zamanda C # -> https://visualstudio.uservoice.com/forums/121579-visual-studio/category/30931-languages-c için en çok oy alan 2. özellik olarak listelenmiştir.

Null kötüdür. Bununla birlikte, boş bir eksikliği daha büyük bir kötülük olabilir.

Sorun şu ki, gerçek dünyada çoğu zaman verilerinizin olmadığı bir durum var. Boş değer içermeyen versiyon örneğiniz hala patlayabilir - ya mantıklı bir hata yaptınız ve Goodman'ı kontrol etmeyi unuttum ya da belki Goodman kontrol ettiğinizde ve ona baktığınız zaman evlendi. (Moriarty kodunuzun her parçasını izliyor ve sizi yukarı çıkarmaya çalışıyorsa, bu mantığı değerlendirmenize yardımcı olur.)

Goodman'ın araması orada olmadığı zaman ne yapar? Bir sıfır olmadan, bir tür varsayılan müşteriye geri dönmeniz gerekir - ve şimdi bu varsayılana bir şeyler satıyorsunuz.

Temel olarak, ne ya da doğru çalışması ne olursa olsun, kodun çalışmasının daha önemli olup olmadığı ortaya çıkar. Eğer uygunsuz davranış hiçbir davranışa tercih edilmiyorsa, boş değer istemezsiniz. (Bunun nasıl doğru seçim olabileceğini gösteren bir örnek için, Ariane V'in ilk lansmanını düşünün. Yakalanmamış / 0 hatası, roketin sert bir dönüş yapmasına ve bunun sonucunda parçalandığında kendi kendini imha etmesine neden oldu. aslında, yükseltici yakıldığı anda artık hiçbir amaca hizmet etmiyordu - rutin geri dönüş çöplerine rağmen yörüngeye dönecekti.)

100 üzerinden en az 99 kez null kullanmayı tercih ederdim. Yine de, sevinç için kendi versiyonlarına dikkat ederek atlardım.

En yaygın durum için optimize edin.

Her zaman null değerinin kontrol edilmesi sıkıcıdır - yalnızca Müşteri nesnesini ele geçirip onunla çalışabilmek istersiniz.

Normal durumda, bu sadece iyi çalışması gerekir - sen yukarı bak, nesneyi al ve kullan.

Gelen istisnai durumda size (rastgele) adında bir müşteriyi arıyorsanız, o rekor / nesne var olup olmadığını bilmeden, bu başarısız olduğuna dair bazı göstergeler gerekiyordu. Bu durumda, cevap RecordNotFound istisnasını atmaktır (veya altındaki SQL sağlayıcısının bunu sizin için yapmasına izin veriniz).

Belki bir kullanıcı tarafından girildiği için gelen verilere (parametre) güvenip güvenemeyeceğinizi bilemeyeceğiniz bir durumdaysanız, 'TryGetCustomer (name, out out customer)' seçeneğini de Desen. İnt.Parse ve int.TryParse ile çapraz referans.

İstisnalar değerlendirme değil!

Onlar bir sebep için orada. Eğer kodunuz kötü çalışıyorsa, istisna denilen bir dahi modeli vardır ve size bir şeylerin yanlış olduğunu söyler.

Boş nesneleri kullanmaktan kaçınarak, bu istisnaların bir kısmını saklıyorsunuzdur. Boş gösterici istisnasını iyi yazılmış bir istisnaya dönüştürdüğü OP örneğinden bahsetmiyorum, bu aslında okunabilirliği arttırdığı için iyi bir şey olabilir. Nasıl hiç alırken Opsiyon tipi @Jonas belirttiği gibi çözüm sen istisnalar saklıyorsun.

Üretim uygulamanızda, boş bir seçenek seçmek için düğmeye tıklandığında atılacak istisna yerine, sadece hiçbir şey olmuyor. Boş gösterici istisnası yerine atılır ve muhtemelen bu istisna hakkında bir rapor alırız (birçok üretim uygulamasında olduğu gibi, böyle bir mekanizmaya sahibiz) ve gerçekte düzeltebileceğimizden.

Kodunuzu istisnalardan kaçınarak kurşun geçirmez hale getirmek kötü bir fikirdir; istisna düzelterek, kurşun geçirmez kodunu seçmenizi sağlar.

NullsSorunlu oldukları için açıkça kontrol edilmeleri gerekir, ancak derleyici onları kontrol etmeyi unuttuğunuzu söyleyemez. Bunu yalnızca zaman alan statik analiz size söyleyebilir. Neyse ki, birkaç iyi alternatif var.

Değişkeni kapsam dışına çıkarın. Çok sık, nullbir programcı bir değişkeni çok erken ilan ettiğinde ya da çok uzun süre beklettiğinde yer tutucu olarak kullanılır. En iyi yaklaşım sadece değişkenden kurtulmaktır. Oraya koymak için geçerli bir değeriniz olana kadar beyan etmeyin. Bu, düşündüğünüz kadar zor bir kısıtlama değildir ve kodunuzu çok daha temiz hale getirir.

Boş nesne desenini kullanın. Bazen, eksik bir değer sisteminiz için geçerli bir durumdur. Boş nesne deseni burada iyi bir çözümdür. Sürekli açık kontrollere olan ihtiyacı önler, ancak yine de boş bir durumu temsil etmenize izin verir. Bazılarının iddia ettiği gibi, bu bir "hata koşulu üzerinde kâğıt" değildir, çünkü bu durumda boş bir durum geçerli bir anlamsal durumdur. Olduğu söyleniyor, boş bir durum geçerli bir anlamsal durum değilse, bu modeli kullanmamalısınız . Değişkenini kapsam dışına çıkarmalısın.

Bir Belki / Seçenek kullanın. Her şeyden önce, bu derleyicinin sizi eksik bir değeri kontrol etmeniz gerektiği konusunda uyarmasına izin verir, ancak bir tür açık kontrolü başka bir şeyle değiştirmekten fazlasını yapar. Kullanarak Options, kodunuzu zincirleyebilir ve değeriniz varmış gibi devam ettirebilirsiniz, en son dakikayı tam olarak kontrol etmenize gerek kalmaz. Scala'da örnek kodunuz şuna benzer:

val customer = customerDb getByLastName "Goodman"
val awesomeMessage =
  customer map (c => s"${c.firstName} ${c.lastName} is awesome!")
val notFoundMessage = "There was no customer named Goodman.  How lame!"
println(awesomeMessage getOrElse notFoundMessage)

İkinci satırda, müthiş mesajı oluşturduğumuz yerde, müşterinin bulunup bulunmadığını ve ihtiyacımız olmadığını güzel bir şekilde kontrol etmiyoruz . Birçok satır sonra, hatta biz açıkça ne olur ilgilenmemiz farklı bir modül, içinde olabilir çok son satır kadar değil Optionise None. Sadece bu değil, yapmayı unutmuş olsaydık, kontrol edilmiş türü olmazdı. O zaman bile, açıkça ififade etmeden, çok doğal bir şekilde yapılır .

Cihazın nulltest ettiği bir kullanım durumu sırasında şanslıysanız, yazının sadece iyi olduğu, ancak yolun her adımında açık bir kontrol yapmanız gereken veya tüm uygulamanızın havaya uçtuğu bir kontrast ile karşılaştırılması . Sadece uğraşmaya değmez.

NULL'ın temel sorunu, sistemi güvenilmez hale getirmesidir. 1980'de Turing Ödülüne adanmış gazetede Tony Hoare şunları yazdı:

Ve böylece, ADA'nın yaratıcıları ve tasarımcılarına tavsiyem en iyisi görmezden gelindi. .... Bu dilin bugünkü haliyle güvenilirliğin kritik olduğu uygulamalarda kullanılmasına izin vermeyin, örneğin nükleer santraller, seyir füzeleri, erken uyarı sistemleri, antibalistik füze savunma sistemleri. Bir programlama dili hatası nedeniyle yoldan çıkacak bir sonraki roket, Venüs'e zararsız bir yolculukta keşfedilen bir uzay roketi olmayabilir: Kendi şehirlerimizden birinin üzerinde patlayan nükleer bir savaş başlığı olabilir. Güvenilmez programlar üreten bir güvenilmez programlama dili, çevremiz ve toplumumuz için güvensiz otomobillerden, zehirli böcek ilacı veya nükleer santrallerdeki kazalardan çok daha büyük bir risk oluşturmaktadır. Riski azaltmak için değil, riski azaltmak için dikkatli olun.

ADA dili bundan beri çok değişti, ancak bu tür sorunlar Java, C # ve diğer birçok popüler dilde hala mevcut.

Bir müşteri ile tedarikçi arasında sözleşmeler yapmak geliştiricinin görevidir. Örneğin, C # 'da, Java'da olduğu gibi, salt okunur (iki Seçenek) oluşturarak referansın Genericsetkisini en aza indirmek için kullanabilirsiniz :NullNullableClass<T>

class NullableClass<T>
{
     public HasValue {get;}
     public T Value {get;}
}

ve sonra kullanın

NullableClass<Customer> customer = dbRepository.GetCustomer('Mr. Smith');
if(customer.HasValue){
  // one logic with customer.Value
}else{
  // another logic
} 

veya C # extension yöntemleriyle iki seçenek stili kullanın:

customer.Do(
      // code with normal behaviour
      ,
      // what to do in case of null
) 

Fark önemli. Bir yöntemin müşterisi olarak ne bekleyeceğinizi biliyorsunuz. Bir takım kurala sahip olabilir:

Bir sınıf NullableClass türünde değilse, örneği boş olmamalıdır .

Ekip, bu fikri Sözleşme ile Tasarım ve derleme zamanında statik kontrol kullanarak , örneğin ön koşulla:

function SaveCustomer([NotNullAttribute]Customer customer){
     // there is no need to check whether customer is null 
     // it is a client problem, not this supplier
}

veya bir dize için

function GetCustomer([NotNullAndNotEmptyAttribute]String customerName){
     // there is no need to check whether customerName is null or empty 
     // it is a client problem, not this supplier
}

Bu yaklaşım, uygulama güvenilirliğini ve yazılım kalitesini büyük ölçüde artırabilir . Sözleşme ile Tasarım bir durumdur Hoare mantığı 1988 yılında ünlü Nesne Tabanlı Yazılım İnşaat kitap ve Eyfel dilinde Bertrand Meyer tarafından doldurulan, ama modern bir yazılım işçiliği Geçersiz Şekilde kullanımda değil.

Hayır.

Bir dilin özel bir değeri hesaba katmaması null, dilin problemidir. Yazarı, her karşılaşmada boş bir değer olasılığı ile açıkça başa çıkmaya zorlayan Kotlin veya Swift gibi dillere bakarsanız , o zaman tehlike yoktur.

Söz konusu dil gibi dillerde, dil nullherhangi bir ^türden bir değer olmasına izin verir , ancak daha sonra bunu kabul etmek için herhangi bir yapı sağlamaz, bu da nullbeklenmedik bir şekilde (özellikle başka bir yerden size iletildiğinde) olaylara yol açar. Böylece çarpışırsınız. Bu kötülük: nullbaşa çıkmadan kullanmanıza izin vermek .

Temel olarak ana fikir, boş gösterici referans sorunlarının çalışma zamanı yerine derleme zamanında yakalanması gerektiğidir. Bu nedenle, bazı nesneler alan bir işlev yazıyorsanız ve kimsenin null başvurusu ile çağırmasını istemiyorsanız, system yazın, bu derleyicinin işlevinize yapılan çağrının hiçbir zaman olmayacağının garantisini vermek için kullanabilmesi için bu gereksinimi belirtmenize izin vermelidir Arayan kişi ihtiyacınızı karşılamıyorsa derleyin. Bu, örneğin türlerinizi dekore etmek veya seçenek türleri (bazı dillerde null olarak da adlandırılabilir) olarak kullanmak gibi birçok yolla yapılabilir, ancak açıkçası derleyici tasarımcıları için çok daha fazla iş vardır.

1960'larda ve 70'lerde, derleyici tasarımcısının bu fikri hayata geçirmediği için anlaşılabilir olduğunu düşünüyorum çünkü makineler kaynaklar açısından sınırlıydı, derleyiciler nispeten basit tutulmalıydı ve hiç kimse bunun ne kadar kötü olacağını bilmiyordu. yıl aşağı çizgi.

Buna karşı basit bir itirazım var null:

Belirsizlik getirerek kodunuzun anlamını tamamen bozar .

Çoğu zaman sonucun belirli bir türde olmasını beklersiniz . Bu anlamsal olarak ses. Diyelim, veritabanından belirli bir kullanıcı için belirli bir soru sordunuz, idözgeçmişin belirli bir türde (= user) olmasını beklersiniz . Ancak, bu kimliğin kullanıcısı yoksa? Bir (kötü) çözüm: bir nulldeğer eklemek . Böylece sonuç belirsizdir : ya öyle userya da öyle null. Ancak nullbeklenen tip değil. İşte kod kokusunun başladığı yer burasıdır .

Kaçınmada null, kodunuzu semantik olarak netleştiriyorsunuz.

Her zaman etrafta yol vardır null: koleksiyonlara yeniden bakmak Null-objects, optionalsvb.

Bunun için bir değer hesaplamak üzere kod çalıştırılmadan önce erişilen referans veya işaretçi tipindeki bir depolama konumunun semantik olarak mümkün olması durumunda, ne olması gerektiği konusunda mükemmel bir seçenek yoktur. Bu konumların varsayılan olarak serbestçe okunabilen ve kopyalanabilen, ancak referanslara alınmadıklarında veya indekslendiklerinde hatalı olacak olan işaretçi referanslarını varsayılan olarak alması olası bir seçimdir. Diğer seçenekler şunlardır:

1. Konumları varsayılan olarak bir boş göstericiye getirin, ancak kodun kendilerine bakmasına izin vermeyin (hatta null olduklarını bile belirlemez) Muhtemelen boş bir işaretçi ayarlamak için açık bir yol sağlar.
2. Konumları varsayılan olarak bir boş göstericiye getirin ve bir tane okuma girişiminde bulunulursa kilitlenir, ancak bir göstericinin boş tutup tutmadığını test etmek için kilitlenmeyen bir yöntem sunar. Ayrıca, bir işaretçiyi null değerine ayarlamak için açık bir yol sağlar.
3. Belirtilen türün derleyici tarafından sağlanan belirli bir varsayılan örneğine işaretçiyi varsayılan olarak konumlandırın.
4. Belirtilen türün program tarafından sağlanan belirli bir varsayılan örneğine işaretçiyi varsayılan olarak konumlara getirin.
5. Herhangi bir boş gösterici erişimine sahip olmanız (sadece referans işlemleri değil) bir örnek sağlamak için program tarafından sağlanan rutini çağırır.
6. Dil semantiğini, geçici olarak erişilemeyen bir derleyici dışında, başlangıç ​​rutinleri tüm üyelerde çalıştırılana kadar (bir dizi kurucuya benzer bir örnek, varsayılan bir örnekle tedarik edilmek zorunda kalacaktı), depolama yerlerinin koleksiyonları olmayacak şekilde tasarlayın. bir örneği döndürecek bir işlev veya muhtemelen bir işlev çifti - biri örneği döndürmek için diğeri, dizinin yapımı sırasında bir istisna meydana gelirse önceden oluşturulmuş durumlarda çağrılacak olan).

Son tercihin, özellikle hem null hem de null olmayan türler içeren bir dil varsa (biri herhangi bir tür için özel dizi yapıcılarını çağırabilir, ancak null olmayan türlerin dizilerini oluştururken onları çağırmak için gerekli olabilir) bazı çekiciliğe sahip olabilir. ancak boş göstericileri icat ettiği zaman muhtemelen mümkün olmazdı. Diğer seçeneklerden hiçbiri, boş göstericilerin kopyalanmasına izin vermekten, itiraz edilmemesine veya dizine eklenmesine izin vermek kadar çekici görünmemektedir. Yaklaşım # 4 bir seçenek olarak uygun olabilir ve uygulanması oldukça ucuz olmalıdır, ancak kesinlikle tek seçenek olmamalıdır. İşaretçilerin varsayılan olarak belirli bir geçerli nesneye işaret etmeleri gerekmesi, işaretçilerin varsayılan olarak okunamayan veya kopyalanabilen ancak değiştirilemeyen veya dizine eklenmemiş bir boş değere sahip olmasından çok daha kötüdür.

Evet, NULL, nesne yönelimli dünyada korkunç bir tasarım . Özet olarak, NULL kullanımı şunlara yol açar:

• geçici hata işleme (istisnalar yerine)
• belirsiz anlamsal
• hızlı başarısızlık yerine yavaş
• bilgisayarla düşünme vs nesne düşünme
• değiştirilebilir ve eksik nesneler

Ayrıntılı bir açıklama için bu blog gönderisine bakın: http://www.yegor256.com/2014/05/13/why-null-is-bad.html