Nesneyi bir API üzerinden, şema JSON formatında olduğu gibi aktarırken, varolmayan string özelliğini döndürmenin ideal yolu nedir? Bunu yapmanın, aşağıda listelenen bağlantılardaki örneklerde olduğu gibi farklı yolları olduğunu biliyorum.

• Null kaçının
• Boş ver
• Boş özelliği kaldır

Eminim geçmişte null kullandım ama bunu yapmak için iyi bir nedenim yok. Veritabanını ele alırken null kullanmak oldukça kolay görünüyor. Ancak veritabanı API'nin diğer tarafındaki tarafla ilgilenmemesi gereken bir uygulama detayına benziyor. Örneğin, muhtemelen sadece değerleri olan (null olmayan) özellikleri saklayan bir şema veri deposu kullanıyorlar.

Kod açısından dize işlevlerini yalnızca tek bir türle string( yani boş değil) çalışacak şekilde kısıtlama , ispatlamalarını kolaylaştırır; sıfırdan kaçınmak, Optionnesneye sahip olmanın bir nedenidir . Bu nedenle, istek / yanıt üreten kod null kullanmıyorsa, benim tahminim API'nin diğer tarafındaki kod da null kullanmak zorunda kalmayacak.

Boş bir dizgiyi boş kullanmaktan kaçınmanın kolay bir yolu olarak kullanma fikrini seviyorum. Null ve boş dizgelere karşı kullandığımı duyduğum bir argüman, boş dizgenin özelliğin var olduğu anlamına gelir. Farkı anlasam da, bunun sadece uygulama detayı olup olmadığını da merak ediyorum ve boş ya da boş bir string kullanmak, gerçek bir yaşam farkı yaratıyor mu? Ayrıca boş bir dizenin boş bir diziye benzer olup olmadığını da merak ediyorum.

Peki, bu endişeleri gidermek için yapmanın en iyi yolu hangisidir? Aktarılan nesnenin formatına mı bağlı (şema / şema)?

TLDR; Boş özellikleri kaldır

Akılda tutulması gereken ilk şey, kenarlarındaki uygulamaların nesne yönelimli olmamasıdır (ya da bu paradigmada programlama yapılırsa işlevsel değildir). Aldığınız JSON bir nesne değildir ve bu şekilde değerlendirilmemelidir. Sadece bir nesneye dönüşebilecek (veya değiştirmeyecek) yapılandırılmış verilerdir. Genel olarak, gelen hiçbir JSON, böyle doğrulanana kadar bir iş nesnesi olarak güvenilmemelidir. Sadece seri hale getirilmiş olması onu geçerli kılmaz. JSON'un arka uç dillere kıyasla sınırlı ilkeleri olması nedeniyle, gelen veriler için JSON hizalanmış bir DTO yapılması genellikle faydalı olacaktır. Ardından, API işlemini çalıştırmak için bir iş nesnesi (veya bir hata denemesi) oluşturmak için DTO kullanın.

JSON'a yalnızca bir aktarım biçimi olarak baktığınızda, ayarlanmamış özellikleri atlamak daha mantıklı olur. Telin üzerinden göndermek daha az. Arka uç diliniz varsayılan olarak null kullanmıyorsa, muhtemelen seriyi temizleyicinizi bir hata verecek şekilde yapılandırabilirsiniz. Örneğin, Newtonsoft.Json için ortak kurulumum boş / eksik özellikleri optionyalnızca F # tiplerine çevirir ve aksi halde hata verir. Bu, hangi alanların isteğe bağlı olduğunu ( optiontüründekiler) doğal olarak gösterir .

Her zamanki gibi, genellemeler seni çok uzaklara götürür. Varsayılan veya boş bir özelliğin daha iyi uyduğu durumlar olabilir. Ancak, anahtar, sisteminizin kenarındaki veri yapılarına iş nesneleri olarak bakmak değildir. İş nesneleri, başarılı bir şekilde oluşturulduğunda iş garantileri (örneğin, en az 3 karakter adı) taşımalıdır. Ancak kabloyu çeken veri yapılarının gerçek bir garantisi yoktur.

Güncelleme: Yanıtı biraz düzenledik, çünkü karışıklığa neden olabilir.

Boş bir dizeyle devam etmek kesin bir sayıdır. Boş dize hala bir değerdir, sadece boştur. Hiçbir şeyi temsil etmeyen bir yapı kullanılarak hiçbir değer belirtilmemelidir null.

API geliştiricisinin bakış açısından sadece iki tür özellik vardır:

• Gerekli (bunlar kendilerine özgü bir değere sahip olmalı ve hiç boş olmamalıdır),
• isteğe bağlı (bu MAY kendi türünde bir değer içerir, ancak MAY da içerebilir null.

Bu, bir mülk zorunlu olduğu zaman, yani, açıkça göstermektedir. gerekli, asla olamaz null.

Öte yandan, bir nesnenin isteğe bağlı bir özelliği ayarlanıp boş bırakılmaması durumunda, nulldeğeri yine de yanıtta tutmayı tercih ederim . Tecrübelerime göre, API istemcilerinin bir özelliğin gerçekten var olup olmadığını kontrol etmeleri gerekmediğinden, her zaman orada olduğu için yanıtlamayı uygulamalarını kolaylaştırır ve yanıtı nulldeğerleri özel muamele ile özel DTO'larına dönüştürebilirler. isteğe bağlı olarak.

İstemcilerde ek koşullar da dahil olmak üzere, yanıt kuvvetlerinden alanları dinamik olarak ekleme / çıkarma.

Her iki şekilde de, hangisini seçerseniz seçin, tutarlı ve iyi belgelenmiş olduğundan emin olun . Bu şekilde, davranışınız öngörülebildiği sürece API'niz için ne kullandığınız fark etmez.

null Kullanım Uygulama / Dil Bağımlı

Sonuç nullolarak geçerli bir uygulama değeri olarak kullanılıp kullanılmayacağının seçimi büyük ölçüde uygulamanız ve programlama dili / arayüzü / kenarı tarafından belirlenir.

Temel düzeyde, farklı değer sınıfları varsa, farklı türler kullanmayı denemeyi tavsiye ederim. nullArayüzünüz izin veriyorsa ve temsil etmeye çalıştığınız bir özelliğin yalnızca iki sınıfı varsa bir seçenek olabilir. Arabiriminiz veya biçiminiz izin veriyorsa, bir özelliği atlamak bir seçenek olabilir. Yeni bir toplu tür (sınıf, nesne, ileti türü) başka bir seçenek olabilir.

Dize örneğiniz için eğer bu programlama dilinde ise kendime birkaç soru sorarım.

1. Gelecekteki değer türlerini eklemeyi planlıyorum mu? Eğer öyleyse, Optionmuhtemelen arayüz tasarımı için daha iyi olacaktır.
2. Tüketici aramalarını ne zaman doğrulamam gerekir? Statik? Dinamik? Önce? Sonra? Hiç mi? Programlama diliniz destekliyorsa, doğrulama için oluşturmanız gereken kod miktarını önlediği için statik yazmanın avantajlarını kullanın. OptionEğer dize nullable değilse muhtemelen bu durumu en iyi şekilde doldurur. Ancak, muhtemelen yine de kullanıcı girişini bir nulldize değeri için kontrol etmeniz gerekecek , bu yüzden muhtemelen ilk sorgulama hattına geri döneceğim: kaç tür değer göstermek / temsil etmek isteyeceğim.
3. Mı nullbenim programlama dilinde bir programcı hatası göstergesidir? Ne yazık ki, nullgenellikle bazı dillerde başlatılmamış (veya açıkça başlatılmamış) işaretçiler veya referanslar için varsayılan değerdir. Mı nullvarsayılan değer olarak kabul edilebilir bir değer olarak? Öyle mi güvenli varsayılan değer olarak? Bazen nulltahsis edilen değerlerin göstergesidir. Arayüzümün tüketicilerine bu potansiyel bellek yönetimi veya başlatma problemlerini programlarında göstermeli midir? Bu tür bir aramanın bu tür problemler karşısında başarısızlık modu nedir? Arayan kişi benimkiyle aynı süreçte mi yoksa iş parçacığında mı, bu tür hatalar benim başvurum için yüksek bir risk oluşturacak mı?

Bu sorulara verdiğiniz cevaplara bağlı olarak, muhtemelen nullarayüzünüz için doğru olup olmadığına karar verebileceksiniz .

örnek 1

1. Başvurunuz güvenlik açısından kritik
2. Başlangıçta bir tür yığın başlatması kullanıyorsunuzdur ve nullbir dizeye yer ayırma başarısızlığında geri geçen olası bir dize değeridir.
3. Böyle bir dize arayüzüne isabet potansiyel

Cevap: nullmuhtemelen uygun değildir

Gerekçe: nullBu durumda aslında iki farklı değer tipini belirtmek için kullanılır. İlki, arayüzünüzdeki kullanıcının ayarlamak istediği varsayılan bir değer olabilir. Ne yazık ki, ikinci değer, sisteminizin doğru çalışmadığını gösteren bir işarettir. Bu gibi durumlarda, muhtemelen mümkün olduğu kadar güvenli bir şekilde başarısız olmak istersiniz (sisteminiz için ne anlama gelirse).

Örnek 2

1. char *Üyesi olan bir C yapısı kullanıyorsunuz .
2. Sisteminiz yığın tahsisi kullanmıyor ve MISRA denetimini kullanıyorsunuz.
3. Arayüzünüz bu yapıyı bir işaretçi olarak kabul eder ve yapının işaret etmediğinden emin olmak için denetler. NULL
4. API'niz için char *üyenin varsayılan ve güvenli değeri tek bir değerle belirtilebilir.NULL
5. Kullanıcınızın yapı başlatması üzerine, kullanıcıya char *üyeyi açıkça başlatmayan bir fırsat sağlamak istersiniz .

Cevap: NULLuygun olabilir

Gerekçe: Yapınızın NULLkontrolden geçmesi ancak başlatılmaması için küçük bir şans var . Ancak, yapı değerinde ve / veya yapı adresinin aralık denetlemesinde bir miktar sağlama toplamı sağlamadığınız sürece API'nız bunu hesaplayamayabilir. MISRA-C gömlekleri, API'lerin kullanıcılarına, başlangıçtan önce yapıların kullanımını işaretleyerek yardımcı olabilir. Bununla birlikte, char *üyeye göre, yapı işaretçisi, başlatılmış yapıya işaret ediyorsa, yapı belirleyicisinde yapı belirleyicisinin NULLvarsayılan değeridir. Bu nedenle, uygulamanızdaki yapı üyesi NULLiçin güvenli, varsayılan bir değer olabilir char *.

Bir seri hale getirme arabirimindeyse, bir dizede boş kullanılıp kullanılmayacağı hakkında kendime şu soruları sorarım.

1. Mı nullpotansiyel bir müşteri tarafı hatası göstergesidir? JavaScript'teki JSON için, bu muhtemelen bir nulltahsisat hatası göstergesi olarak kullanılmasının zorunlu olmadığı bir rakamdır. JavaScript'te, sorunlu olarak ayarlanacak bir referanstan nesne yokluğunun açık bir göstergesi olarak kullanılır. Bununla birlikte, JSON'u nullyerel tiple eşleyen javascript olmayan ayrıştırıcılar ve serileştiriciler var null. Bu durumda, kendi nulldiliniz, ayrıştırıcı ve seri hale getirici birleşimi için yerel kullanımın uygun olup olmadığının tartışılması için yalvarır .
2. Bir mülk değerinin açıkça yokluğu, tek bir mülk değerinden daha fazlasını etkiler mi? Bazen a nullaslında tamamen yeni bir mesaj tipine sahip olduğunuzu gösterir. Tüketicileriniz için, tamamen farklı bir mesaj türü belirtmesi için seri hale getirme formatı daha temiz olabilir. Bu, doğrulama ve uygulama mantığının, web arayüzünüzün sağladığı iki mesaj ayrımı arasında temiz bir ayrım yapmasını sağlar.

Genel tavsiye

nullbir kenarı veya arayüzde onu desteklemeyen bir değer olamaz. Özelliklerin değerlerini (örn. JSON) yazarken doğada aşırı derecede gevşek olan bir şey kullanıyorsanız, eğer mümkünse , tüketici kenarı yazılımında (örn. JSON Schema ) bir şema veya doğrulama formu yüklemeye çalışın . Bir programlama dili API'sı ise, kullanıcı girişini mümkünse statik olarak (yazarak) veya çalışma süresinde duyarlı olduğu kadar yüksek sesle doğrulayın (diğer bir deyişle , müşteriye dönük arabirimlerde savunma programlama yapın ). En önemlisi, kenarı belgeleyin veya tanımlayın, böylece:

• Bir mülkün hangi tür değerlerini kabul ettiği
• Belirli bir mülk için hangi değer aralıkları geçerlidir?
• Bir toplu türün nasıl yapılandırılması gerektiği. Agrega tipinde hangi özellikler olmalı / gerekir / mevcut olabilir?
• Bir tür konteynırsa, konteynır kaç öğeyi tutabilir veya tutabilir ve bu kabın sahip olduğu değer türleri nelerdir?
• Bir kapsayıcının veya toplu türün özellikleri veya örnekleri varsa hangi sırayı alıyorsunuz?
• Belirli değerleri belirlemenin hangi yan etkileri vardır ve bu değerleri okumanın yan etkileri nelerdir?

İşte bu soruları benim kişisel analizim. Herhangi bir kitap, makale, çalışma ya da her neyse, sadece benim kişisel deneyimim tarafından desteklenmiyor.

Boş dizeler null

Bu benim için bir no-go. Boş dizgenin anlamını tanımlanmamış olanlarla karıştırmayın. Pek çok durumda, bunlar mükemmel bir şekilde birbirleriyle değiştirilebilir olabilir, ancak tanımlanmamış ve tanımlanmamış ancak boş olanların farklı bir şey ifade ettiği durumlar ile karşılaşabilirsiniz.

Bir tür aptal örnek: diyelim ki yabancı bir anahtarı saklayan bir özellik var ve bu özellik tanımlanmamış veya değil null, bu tanımlanmış bir ilişki olmadığı anlamına gelir, oysa boş bir dize ""tanımlanmış bir ilişki olarak anlaşılabilir. Yabancı kaydın kimliği şu boş dizedir.

Tanımlanmamış vs null

Bu siyah veya beyaz bir konu değil. Her iki yaklaşımın da artıları ve eksileri var.

Açıkça tanımlayıcı nulldeğerler lehine , bu artıları vardır:

• Mesajlar daha açıklayıcıdır, çünkü tüm anahtarları sadece herhangi bir mesaja bakarak öğrenebilirsiniz.
• Bir önceki noktaya göre, verilerin tüketicisindeki hataları kodlamak ve tespit etmek daha kolaydır: yanlış anahtarları alırsanız (belki yanlış yazım, belki API değişti, vb.) Hataları tespit etmek daha kolaydır.

Mevcut olmayan bir anahtarın varsayılması lehine şu anlama gelir null:

• Bazı değişikliklerin yapılması daha kolaydır. Örneğin, mesaj şemasının yeni bir sürümü yeni bir anahtar içeriyorsa, mesajın üreticisi güncellenmemiş ve bu bilgiyi henüz sunmamış olsa bile, bu gelecek anahtarla çalışacak bilginin tüketicisini kodlayabilirsiniz.
• Mesajlar daha az ayrıntılı veya daha kısa olabilir

API'nin bir şekilde kararlı olması ve tamamen belgelenmesi durumunda, var olmayan bir anahtarın anlamına eşit olduğunu belirtmenin tamamen uygun olduğunu düşünüyorum null. Fakat eğer daha dağınık ve karmakarışıksa (sıkça olduğu gibi), her mesajdaki her bir değeri açıkça tanımlarsanız baş ağrılarından kaçınabileceğinizi düşünüyorum. Başka bir şüphem varsa ayrıntılı yaklaşımı takip etme eğilimindeyim.

Her şeyden önce, en önemli şey: niyetlerinizi açıkça belirtin ve tutarlı olun. Burada bir şeyi, diğeri orada yapmayın. Tahmin edilebilir yazılım daha iyi bir yazılımdır.

Bir dizgenin bulunduğu bir durumda boş bir dize tedarik ederdim ve bu boş bir dize olur. Açıkça "hayır, bu veri yok" demek istediğim bir durumda null verecektim. Ve "orada veri yok, canını sıkma" deme anahtarını atlayın.

Bu durumlardan hangisinin olabileceğine karar verirsiniz. Uygulamanızın boş dizeleri olması mantıklı geliyor mu? Açıkça "veri yok" demeyi null kullanarak ya da hiçbir değere sahip olmadan örtük olarak ayırt etmek ister misiniz? Her ikisinin de müşteri tarafından ayırt edilmesi gerekiyorsa, yalnızca iki seçeneğiniz de (boş ve anahtar yok) olmalıdır.

Şimdi bunun tümünün veri aktarımı ile ilgili olduğunu unutmayın. Alıcının verilerle yaptığı şey onların işidir ve onlar için en uygun olanı yapacaklardır. Alıcı , üzerine attığınız herhangi bir şeyi (muhtemelen verileri reddederek) çökmeden idare edebilmelidir.

Başka bir husus yoksa, gönderen için en uygun olanı iletir ve belgelerim . JSON kodlama, iletme ve ayrıştırma hızını iyileştirme olasılığı yüksek olduğundan, hiç eksik değerler göndermemeyi tercih ederim.

Neyin en iyisi olduğunu söyleyemem ama kesinlikle basit bir uygulama detayı değil , bu değişkenle nasıl etkileşime girebileceğinizin yapısını değiştiriyor.

Eğer bir şey null olursa, her zaman bir noktada null olacak gibi davranmalısınız , bu nedenle her zaman iki iş akışına sahip olacaksınız , biri boş, diğeri geçerli bir dize. Bölünmüş bir iş akışı mutlaka kötü bir şey değildir, çünkü oldukça fazla hata işleme ve kullanabileceğiniz özel durum kullanımları vardır, ancak kodunuzu gizler.

Dizeyle her zaman aynı şekilde etkileşirseniz , işlevselliğin kafanızda kalması muhtemelen daha kolay olacaktır .

Herhangi bir "en iyisi" sorusuyla olduğu gibi cevabını bıraktım: buna bağlı . İş akışınızı bölmek ve bir şey ayarlanmadığında daha açık bir şekilde yakalamak istiyorsanız, null kullanın. Programı devam ettirmek yerine sadece boş bir dize kullanın. Önemli olan, tutarlı olmanız, ortak bir geri dönüş seçmeniz ve buna bağlı kalmaktır.

Eğer bir API oluştururken göz önüne alındığında, ben tavsiye ederim boş bir dizeye yapışmasını kullanıcı, çünkü telafi etmek için daha az olarak orada ben API bana boş değer verebilir her türlü nedene anlayamayacaksınız bir API kullanıcısı olarak 'sürece Çok iyi belgelenmiş, bazı kullanıcılar zaten okumaz.

Belge!

TL; DR>

Uygun gördüğünüzü yapın - bazen kullanıldığı bağlam önemlidir. Örnek, Değişkenleri Oracle SQL'e Bağlama: Boş Dize NULL olarak yorumlanır.

Basitçe söylemek gerekirse - Bahsedilen her senaryoyu belgelendiğinizden emin olun

• BOŞ
• Boş (boş)
• Eksik (kaldırıldı)

Kodunuz farklı şekillerde hareket edebilir - kodunuzun ona nasıl tepki gösterdiğini belgeleyin:

• Hata (İstisna vb.), Belki de doğrulama başarısız olur (muhtemelen işaretli bir istisna) vs durumu doğru şekilde ele alamaz (NullPointerException).
• Makul varsayılanlar sağlayın
• Kod farklı davranır

O zaman buna ek olarak - tutarlı davranmak ve muhtemelen kendi en iyi uygulamalarınızın bazılarını benimsemek sizin sorumluluğunuzdadır. Tutarlı davranışı belgeleyin. Örnekler:

• Boş davran ve aynı şeyi kaçır
• Boş bir dizeye aynen böyle davranın. Sadece bir SQL bağlantısı durumunda, boş olarak kabul edilebilir. SQL'inizin sürekli ve beklenilen şekilde davrandığından emin olun.

tl; dr - kullanırsanız: ne anlama geldiğine tutarlı olun.

Eğer dahil edersen null, bunun anlamı ne olurdu? Ne anlama gelebileceği konusunda bir şeyler dünyası var. Bir değer, eksik veya bilinmeyen bir değeri temsil etmek için yeterli değildir (ve bunlar sayısız olasılıktan sadece ikisidir: örn. Kayıp - ölçülmüştür, ancak henüz bilmiyoruz. Bilinmiyor) - ölçmeye çalışmadık o.)

Son zamanlarda karşılaştığım bir örnekte, bir kişinin gizliliğini koruduğu bildirilmeyen bir alan boş olabilirdi, ancak gönderenin tarafında bilinmiyordu, gönderenin yanında bilinmiyordu, ancak orijinal muhabiri biliyordu veya her ikisi de bilinmiyor. Ve bunların hepsi alıcı için önemliydi. Bu yüzden genellikle bir değer yeterli değildir.

Açık bir dünya varsayımıyla (sadece belirtilmeyen şeyleri bilmiyorsunuz), onu dışarıda bırakacaktınız ve herhangi bir şey olabilirdi. Kapalı dünya varsayımıyla (belirtilmeyen şeyler yanlış, örneğin SQL'de), ne nullanlama geldiğini ve bu tanımla tutarlı olmanın ne anlama geldiğini açıkça belirtmelisiniz ...