Bir değer anlamlı bir şekilde bulunamadığında, yeni bir Boole alanı boş başvurudan daha mı iyidir?

Örneğin Member, bir lastChangePasswordTime olan bir sınıfım olduğunu varsayalım:

class Member{
  .
  .
  .
  constructor(){
    this.lastChangePasswordTime=null,
  }
}

lastChangePasswordTime, anlamsız olabilir, çünkü bazı üyeler şifrelerini asla değiştiremez.

Ancak boş değerlerin kötü olması durumunda, bir değer anlamlı olarak bulunamadığında neler kullanılmalıdır? ve https://softwareengineering.stackexchange.com/a/12836/248528 , anlamlı olmayan bir değeri temsil etmek için null kullanmamalıyım. Bu yüzden bir Boolean bayrağı eklemeye çalışıyorum:

class Member{
  .
  .
  .
  constructor(){
    this.isPasswordChanged=false,
    this.lastChangePasswordTime=null,
  }
}

Ancak bunun oldukça eski olduğunu düşünüyorum:

1. İsPasswordChanged yanlış olduğunda, lastChangePasswordTime değeri null olmalıdır ve lastChangePasswordTime == null değerinin kontrol edilmesi neredeyse aynıdır isPasswordChanged değerinin yanlış olması nedeniyle, lastChangePasswordTime == null öğesinin doğrudan kontrol edilmesini tercih ederim

2. Buradaki mantığı değiştirirken, her iki alanı da güncellemeyi unutabilirim .

Not: Bir kullanıcı şifreleri değiştirdiğinde, şu zamanı kaydederim:

this.lastChangePasswordTime=Date.now();

Ek Boole alanı burada boş başvurudan daha mı iyi?

Eğer anlamsız bir değeriniz nullyoksa, kasten ve dikkatli olmanız durumunda neden kullanılmaması gerektiğini anlamıyorum.

Amacınız, yanlışlıkla başvurmayı önlemek için boş değeri çevrelemekse, değeri isPasswordChangedboş bir denetimin sonucunu döndüren bir işlev veya özellik olarak oluşturmanızı öneririm , örneğin:

class Member {
    DateTime lastChangePasswordTime = null;
    bool isPasswordChanged() { return lastChangePasswordTime != null; }

}

Bence, bu şekilde yapmak:

• Bağlamı kaybedebilecek bir boş denetlemeden daha iyi kod okunabilirliği sağlar.
• Bahsettiğiniz isPasswordChangeddeğeri korumak konusunda gerçekten endişelenmenize gerek kalmaması ihtiyacını ortadan kaldırıyor.

Verileri sürdürme şekliniz (muhtemelen bir veritabanında), boş değerlerin korunmasını sağlamaktan sorumlu olacaktır.

nullskötü değil. Onları düşünmeden kullanmak. Bu nulltam olarak doğru cevabın verildiği bir durumdur - tarih yoktur.

Çözümünüzün daha fazla sorun yarattığını unutmayın. Tarihin bir şeye ayarlanmasının anlamı nedir, ama isPasswordChangedyanlış mı? Bir nulldeğerin açıkça tanımlanmış, açık bir anlamı olduğu ve diğer bilgilerle çakışamadığı durumlarda, özel olarak yakalamanız ve tedavi etmeniz gereken bir çakışan bilgi durumu oluşturdunuz .

Yani hayır, çözümünüz daha iyi değil. Bir nulldeğere izin vermek , buradaki doğru yaklaşımdır. nullDurum ne olursa olsun kötülük olduğunu iddia eden insanlar neden nullvar olduğunu anlamıyorlar .

Programlama diline bağlı olarak, optionalveri türü gibi iyi alternatifler olabilir . C ++ (17) 'de, std :: isteğe bağlı olacaktır . Yok olabilir veya temel veri türünün keyfi bir değeri olabilir.

Doğru null kullanarak

Kullanmanın farklı yolları var null. En yaygın ve anlamsal olarak doğru yol, tek bir değere sahip olabileceğinize veya sahip olamayacağınız zaman kullanmaktır . Bu durumda, bir değer ya nullveri tabanındaki bir kayıt gibi bir şeye eşittir veya buna benzer bir şeydir.

Bu durumlarda, daha sonra çoğunlukla bu şekilde kullanın (sözde kodda):

if (value is null) {
  doSomethingAboutIt();
  return;
}

doSomethingUseful(value);

Sorun

Ve çok büyük bir problemi var. Sorun şu ki, çağıracağınız zaman doSomethingUseful, değeri kontrol etmemiş olabilirsiniz null! Öyle değilse, program muhtemelen çökecektir. Ve kullanıcı, "korkunç hata: aranan değer ama boş aldı!" Gibi bir şeyle bırakılarak, iyi bir hata mesajı bile görmeyebilir. (güncellemeden sonra: Segmentation fault. Core dumped.bazı durumlarda null hakkında hiçbir hata ve yanlış manipülasyon gibi , hatta daha da kötüsü gibi daha az bilgilendirici bir hata olsa da)

Durumlar için çek yazmayı nullve işlemeyi unutmak oldukça yaygın bir hatadır . Bu nedenle , 2009'da QCon Londra adlı bir yazılım konferansında, 1965'te milyar dolarlık bir hata yaptığını söyleyen Tony Hoare’in : https://www.infoq.com/presentations/Null-References-The-Billion-Dollar- hata-Tony-Hoarenullnull

Sorunu önlemek

Bazı teknolojiler ve diller nullfarklı şekillerde unutmayı imkansız hale getirir ve böcek miktarını azaltır.

Örneğin Haskell, Maybeboş değer yerine monad'a sahiptir. Bunun DatabaseRecordkullanıcı tarafından tanımlanan bir tür olduğunu varsayalım . Haskell'de bir tür değer Maybe DatabaseRecordeşit Just <somevalue>veya eşit olabilir Nothing. Daha sonra farklı şekillerde kullanabilirsiniz, ancak nasıl kullanıyor olursanız olun, Nothingbilmeden bazı işlemleri uygulayamazsınız .

Örneğin, çağrılan bu işlev için ve için zeroAsDefaultdöndürür :xJust x0Nothing

zeroAsDefault :: Maybe Int -> Int
zeroAsDefault mx = case mx of
    Nothing -> 0
    Just x -> x

Christian Hackl, C ++ 17 ve Scala'nın kendi yöntemlerinin olduğunu söylüyor. Dolayısıyla, dilinizde böyle bir şey olup olmadığını öğrenmeyi denemek isteyebilirsiniz.

Null hala geniş kullanımda

Daha iyi bir şeyiniz yoksa kullanmak nulliyidir. Sadece izlemeye devam et. İşlevlere bildirim yazın, yine de size yardımcı olacaktır.

Ayrıca bu çok ilerici görünmeyebilir ancak meslektaşlarınızın kullanmak nullveya başka bir şey isteyip istemediğinizi kontrol etmeniz gerekir . Muhafazakar olabilir ve bazı nedenlerden dolayı yeni veri yapılarını kullanmak istemeyebilirler. Örneğin bir dilin daha eski sürümlerini desteklemektedir. Bu tür şeyler projenin kodlama standartlarında ilan edilmeli ve ekiple uygun şekilde tartışılmalıdır.

Teklifin üzerine

Ayrı bir boole alanı kullanmanızı öneririz. Ama yine de kontrol etmelisin ve yine de kontrol etmeyi unutabilirsin. Yani burada kazanılan hiçbir şey yok. Başka bir şeyi bile unutabilirseniz, her seferinde her iki değeri de güncellemek gibi, o zaman daha da kötüdür. Kontrol etmeyi unutma sorunu nullçözülmediyse, bunun anlamı yoktur. Sakınmak nullzordur ve onu daha da kötüleştirecek şekilde yapmamalısınız.

Null kullanılmaz

Son olarak nullyanlış kullanmanın yaygın yolları vardır . Bu yollardan biri, diziler ve dizgiler gibi boş veri yapıları yerine kullanmaktır. Boş bir dizi, diğerleri gibi uygun bir dizidir! Birden fazla değere uyan, boş olabilen, yani 0 uzunluğa sahip veri yapıları için hemen hemen her zaman önemli ve kullanışlıdır.

Cebir açısından, dizgiler için boş bir dize, sayılar için 0'a çok benzer, yani kimlik:

a+0=a
concat(str, '')=str

Boş dize, dizelerin genel olarak monoid hale gelmesini sağlar: https://en.wikipedia.org/wiki/Monoid Bunu elde edemezseniz, sizin için o kadar önemli değildir.

Şimdi bu örnekle programlama için neden önemli olduğunu görelim:

for (element in array) {
  doSomething(element);
}

Burada boş bir dizi geçirirsek kod iyi çalışır. Sadece hiçbir şey yapmaz. Ancak bir nullburadan geçersek, "null üzerinden geçemiyorum, üzgünüm" gibi bir hatayla karşılaşacağız. İçeri sarabiliriz ifama bu daha az temiz ve tekrar, kontrol etmeyi unutabilirsin

Null nasıl kullanılır

Yapması doSomethingAboutIt()gereken ve özellikle de bir istisna atıp atmaması gerekip gerekmediği bir başka karmaşık konudur. Kısacası null, verilen bir görev için kabul edilebilir bir girdi değerinin olup olmadığına ve bunun cevabında beklenenin ne olduğuna bağlıdır . İstisnalar, beklenmeyen olaylar içindir. Bu konuya daha fazla girmeyeceğim. Bu cevap çok uzun zamandır.

Daha önce verilen çok iyi cevapların hepsine ek olarak, bir alanın boş olmasına izin vermek istediğinizde, bir liste türü olup olmadığını dikkatlice düşünün. NULL olabilecek bir tür eşdeğerde 0 veya 1 öğelerin bir listesidir ve bu genellikle N öğelerinin bir listesine genellenebilir. Özellikle bu durumda, lastChangePasswordTimebir liste olarak düşünebilirsiniz passwordChangeTimes.

Kendinize sorun: hangi davranış lastChangePasswordTime alanını gerektiriyor?

IsPasswordExpired () yöntemi için bu alana bir Üyenin şifresini sık sık değiştirmesinin istenip istenmeyeceğini belirlemek için ihtiyaç duyuyorsanız, alanı başlangıçta Üyenin oluşturulduğu zamana ayarlarım. IsPasswordExpired () uygulaması yeni ve mevcut üyeler için aynıdır.

class Member{
   private DateTime lastChangePasswordTime;

   public Member(DateTime lastChangePasswordTime) {
      // set value, maybe check for null
   }

   public bool IsPasswordExpired() {
      DateTime limit = DateTime.Now.AddMonths(-3);
      return lastChangePasswordTime < limit;
   }
}

Yeni oluşturulan üyelerin şifrelerini güncellemek zorunda olmaları için ayrı bir gereksiniminiz varsa , passwordShouldBeChanged adlı ayrı bir boolean alanı ekler ve oluşturulduktan sonra doğru olarak ayarlardım. Daha sonra, bu alana bir denetim eklemek için IsPasswordExpired () yönteminin işlevselliğini değiştirirdim (ve yöntemi ShouldChangePassword olarak yeniden adlandırdım).

class Member{
   private DateTime lastChangePasswordTime;
   private bool passwordShouldBeChanged;

   public Member(DateTime lastChangePasswordTime, bool passwordShouldBeChanged) {
      // set values, maybe check for nulls
   }

   public bool ShouldChangePassword() {
      return PasswordExpired(lastChangePasswordTime) || passwordShouldBeChanged;
   }

   private static bool PasswordExpired(DateTime lastChangePasswordTime) {
      DateTime limit = DateTime.Now.AddMonths(-3);
      return lastChangePasswordTime < limit;
   }
}

Niyetlerinizi kodda açıkça belirtin.

Öncelikle, boş olan şeytan kötülük dogmadır ve her zamanki gibi dogma ile en iyi şekilde bir kılavuz olarak çalışır, pas / pas testi yoktur.

İkincisi, durumunuzu, değerin hiçbir zaman boş olamayacağı mantıklı bir şekilde yeniden tanımlayabilirsiniz. InititialPasswordChanged, başlangıçta false olarak ayarlanmış bir Boolean'dır; PasswordSetTime, geçerli parolanın ayarlandığı tarih ve saattir.

Bunun düşük bir maliyete sahip olmasına rağmen, bir HER ZAMAN şifrenin en son ayarlanmasından bu yana ne kadar süre kaldığını hesaplayabilirsiniz.

Arayan kullanımdan önce kontrol ederse her ikisi de 'güvenli / akıllı / doğru' olur. Sorun, arayan kişi kontrol etmezse ne olacağıdır. Hangisi daha iyi, bazı null hata lezzet veya geçersiz bir değer kullanıyor?

Tek bir doğru cevap yok. Neye endişelendiğine bağlı.

Çarpışmalar gerçekten kötüyse ancak cevap kritik değilse veya kabul edilen bir varsayılan değere sahipse, belki de bir booleanı bayrak olarak kullanmak daha iyidir. Yanlış cevap kullanmak, çökmekten daha kötü bir sorunsa, null kullanmak daha iyidir.

'Tipik' vakaların çoğu için, hızlı başarısızlık ve arayanları kontrol etmeye zorlama kodu, aklı başında kodlama için en hızlı yoldur ve bu nedenle null varsayılan seçenek olmalıdır. “X, tüm kötülüklerin köküdür” iddialarına inanmam; normalde tüm kullanım durumlarını öngörmemişlerdir.