Yapıcı parametre doğrulama C # - En iyi yöntemler

Yapıcı parametre doğrulaması için en iyi yöntem nedir?

Diyelim ki basit bir C # biti:

public class MyClass
{
    public MyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            throw new ArgumentException("Text cannot be empty");

        // continue with normal construction
    }
}

Bir istisna atmak kabul edilebilir mi?

Karşılaştığım alternatif, başlatılmadan önce ön doğrulama yapıldı:

public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
        {
            MessageBox.Show("Text cannot be empty");
            return null;
        }
        else
        {
            return new MyClass(text);
        }
    }
}

Bütün onaylarımı kurucuda yerine getirme eğilimindeyim. Bu bir zorunluluktur çünkü neredeyse daima değişken nesneler yaratıyorum. Özel durumunuz için bunun kabul edilebilir olduğunu düşünüyorum.

if (string.IsNullOrEmpty(text))
    throw new ArgumentException("message", "text");

.NET 4 kullanıyorsanız, bunu yapabilirsiniz. Elbette bu, geçersiz olan sadece beyaz boşluk içeren bir dize olarak düşünmenize bağlıdır.

if (string.IsNullOrWhiteSpace(text))
    throw new ArgumentException("message", "text");

Birçok insan, inşaatçıların istisnalar atmaması gerektiğini belirtiyor. Bu sayfadaki KyleG, örneğin, sadece bunu yapıyor. Açıkçası, neden olmasın bir sebep düşünemiyorum.

C ++ 'da, bir kurucudan bir istisna atmak kötü bir fikirdir, çünkü sizi referans almadığınız başlatılmamış bir nesne içeren ayrılmış bir bellekle bırakır (yani, klasik bir bellek sızıntısı). Muhtemelen stigmanın geldiği yer burasıdır - bir grup eski okul C ++ geliştiricisi, C # öğrenmelerini yarı yarıya arttırdı ve C ++ 'dan bildiklerini uyguladı. O dilde kurucular böylece tersine, Objective-C Apple, başlatma adımdaki tahsisi adımını ayrılmış olabilir istisna atar.

C # başarısız bir çağrıdan bir yapıcıya bellek sızdırmaz. .NET çerçevesindeki bazı sınıflar bile yapıcılarında istisnalar ortaya koyacaktır.

Bir istisna atmak IFF, sınıfın anlamsal kullanımı bakımından tutarlı bir duruma getirilemez. Aksi takdirde yapmayın. Bir nesnenin tutarsız bir durumda olmasına ASLA izin vermeyin. Bu, tam kurucular sağlamayı da içermez (nesneniz aslında tamamen oluşturulmadan önce boş bir kurucu + initialize () olması gibi) ... JUST SAY NO!

Bir tutam, herkes yapar. Geçen gün çok dar kullanılan bir nesne için sıkı bir kapsamda yaptım. Yolun aşağısındaki bir gün, ben veya başkası pratikte bu fişin bedelini ödeyecek.

"Oluşturucu" ile müşterinin nesneyi oluşturmak için aradığı şeyi kastediyorum. Bu, "Oluşturucu" adıyla geçen gerçek bir yapıdan başka bir şey olabilir. Örneğin, C ++ 'da böyle bir şey IMNSHO ilkesini ihlal etmeyecektir:

struct funky_object
{
  ...
private:
  funky_object();
  bool initialize(std::string);

  friend boost::optional<funky_object> build_funky(std::string);
};
boost::optional<funky_object> build_funky(std::string str)
{
  funky_object fo;
  if (fo.initialize(str)) return fo;
  return boost::optional<funky_object>();
}

A'yı yaratmanın tek yolu , gerçek bir “Yapıcı” işi bitirmese bile, geçersiz bir nesnenin var olmasına asla izin vermemek ilkesini funky_objectçağırmaktır build_funky.

Şüpheli kazanç için olsa bile çok fazladan iş var (belki de zarar). Yine de istisna yolunu tercih ederim.

Bu durumda fabrika yöntemini kullanırdım. Temel olarak, sınıfınızın yalnızca özel yapıcıları ve nesnenizin bir örneğini döndüren bir fabrika yöntemine sahip olmasını ayarlayın. İlk parametreler geçersizse, null değerini döndürün ve arama kodunun ne yapacağınıza karar vermesini isteyin.

public class MyClass
{
    private MyClass(string text)
    {
        //normal construction
    }

    public static MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            return null;
        else
            return new MyClass(text);
    }
}
public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        var cls = MyClass.MakeMyClass(text);
        if(cls == null)
             //show messagebox or throw exception
        return cls;
    }
}

Koşullar istisnai durumlar dışında asla istisnalar atmayın. Bu durumda boş bir değerin kolayca geçilebileceğini düşünüyorum. Bu durumda, bu kalıbı kullanmak istisnalardan ve Sınıf sınıfını geçerli tutarken ortaya çıkan performans cezalarından kaçınır.

• Bir yapıcının herhangi bir yan etkisi olmamalıdır.
  • Özel alan başlatma işleminden daha fazlası, yan etki olarak görülmelidir.
  • Yan etkileri olan bir kurucu, Tek Sorumluluk İlkesini (SRP) ihlal eder ve nesne yönelimli programlama (OOP) ruhuna aykırı hareket eder.
• Bir yapıcı hafif olmalı ve asla başarısız olmamalıdır.
  • Örneğin, bir yapıcı içinde bir try-catch bloğu gördüğümde her zaman titriyorum. Bir yapıcı istisnalar veya günlük hataları atmamalıdır.

Bir kişi bu yönergeleri makul bir şekilde sorgulayabilir ve “Ama bu kuralları izlemiyorum ve kodum iyi çalışıyor!” Diyebilir. Buna göre, "Olmazsaya dek, bu doğru olabilir" cevabını veririm.

• Bir yapıcının içindeki istisnalar ve hatalar çok beklenmeyen bir durumdur. Bunu yapmaları söylenmedikçe, gelecekteki programcıların bu yapıcı çağrılarını savunma koduyla çevrelemeye meyilli olmayacaklardır.
• Üretimde herhangi bir şey başarısız olursa, oluşturulan yığın izinin ayrıştırılması zor olabilir. Yığın izlemesinin tepesi yapıcı çağrısına işaret edebilir, ancak yapıcıda birçok şey olur ve başarısız olan gerçek LOC'ye işaret etmeyebilir.
  • Bunun olduğu birçok .NET yığını izini ayrıştırdım.

Sınıfımın ne yaptığına bağlı. MyClass aslında bir veri havuzu sınıfıysa ve parametre metni bir bağlantı dizesiyse, en iyi uygulama bir ArgumentException oluşturmaktır. Ancak, eğer MyClass StringBuilder sınıfı ise (örneğin), boş bırakabilirsiniz.

Bu nedenle, parametre metninin yönteme ne kadar temel olduğuna bağlıdır - nesne boş veya boş bir değere sahip mi?

Tercihim varsayılan bir ayar yapmaktır, ancak Java’nın böyle bir şey yapan "Apache Commons" kütüphanesine sahip olduğunu biliyorum ve bence bu da oldukça iyi bir fikir. Geçersiz değer nesneyi kullanılamaz duruma getirirse, bir istisna atma sorunu görmüyorum; bir dize iyi bir örnek değil, peki ya zavallı adamın DI'siydi? nullBir ICustomerRepositoryarabirim yerine bir değeri geçtiyse işlem yapamazsınız . Böyle bir durumda, bir istisna atmak, olayları ele almanın doğru yolu olduğunu söyleyebilirim.

Eskiden c ++ 'da çalıştığımda, kurucuda ortaya çıkarabileceği bellek sızıntısı probleminden dolayı istisna atamadım, zor yoldan öğrendim. C ++ ile çalışan herkes hafıza sızıntısının ne kadar zor ve sorunlu olduğunu bilir.

Fakat eğer c # / Java kullanıyorsanız, o zaman bu probleminiz yoktur, çünkü çöp toplayıcı belleği toplayacaktır. C # kullanıyorsanız, veri sınırlamalarının garanti altına alındığından emin olmak için mülkün güzel ve tutarlı bir şekilde kullanılması tercih edilir.

public class MyClass
{
    private string _text;
    public string Text 
    {
        get
        {
            return _text;
        } 
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Text cannot be empty");
            _text = value;
        } 
    }

    public MyClass(string text)
    {
        Text = text;
        // continue with normal construction
    }
}

Bir istisna atmak, sınıfınızdaki kullanıcılar için gerçek bir acı olacaktır. Doğrulama bir sorun ise, genellikle nesneyi oluştururken 2 adımlı bir işlem yaparım.

1 - Örnek oluştur

2 - Geri dönüş sonucu olan bir Initialize yöntemini çağırın.

VEYA

Doğrulamayı yapabilen sizin için sınıfı oluşturan bir yöntem / işlev çağırın.

VEYA

Özellikle sevmediğim ama bazılarının sevdiği isal bayrağı var.