Sprawdzanie poprawności parametrów konstruktora w C # - Najlepsze praktyki

Jaka jest najlepsza praktyka do sprawdzania poprawności parametrów konstruktora?

Załóżmy prosty C #:

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

        // continue with normal construction
    }
}

Czy można zgodzić się na wyjątek?

Alternatywą, którą napotkałem, była wstępna weryfikacja, przed utworzeniem wystąpienia:

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);
        }
    }
}

Mam tendencję do wykonywania całej mojej weryfikacji w konstruktorze. Jest to konieczne, ponieważ prawie zawsze tworzę niezmienne obiekty. W twoim konkretnym przypadku myślę, że jest to do przyjęcia.

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

Jeśli używasz platformy .NET 4, możesz to zrobić. Oczywiście zależy to od tego, czy uważasz, że łańcuch zawierający tylko białe znaki jest nieprawidłowy.

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

Wiele osób twierdzi, że konstruktorzy nie powinni wprowadzać wyjątków. Na przykład KyleG na tej stronie właśnie to robi. Szczerze mówiąc, nie mogę wymyślić powodu, dla którego nie.

W C ++ rzucanie wyjątku od konstruktora jest złym pomysłem, ponieważ pozostawia ci przydzieloną pamięć zawierającą niezainicjowany obiekt, do którego nie masz odniesienia (tj. Jest to klasyczny wyciek pamięci). Prawdopodobnie stąd bierze się piętno - grupa oldschoolowych programistów C ++ na wpół rozwinęła naukę języka C # i po prostu zastosowała do tego to, co znali z C ++. Natomiast w Objective-C Apple oddzielił krok alokacji od kroku inicjalizacji, więc konstruktorzy w tym języku mogą zgłaszać wyjątki.

C # nie może wyciec pamięci z nieudanego wywołania konstruktora. Nawet niektóre klasy w środowisku .NET będą zgłaszać wyjątki w swoich konstruktorach.

Zgłoszenie wyjątku IFF klasy nie można wprowadzić w spójny stan w odniesieniu do jej zastosowania semantycznego. W przeciwnym razie nie. NIGDY nie pozwól, aby obiekt istniał w niespójnym stanie. Obejmuje to niedostarczenie kompletnych konstruktorów (np. Posiadanie pustego konstruktora + inicjalizacja () przed faktycznym ukończeniem budowy obiektu) ... TYLKO POWIEDZ NIE!

W skrócie, wszyscy to robią. Zrobiłem to innego dnia dla bardzo wąsko używanego obiektu w wąskim zakresie. Pewnego dnia, ja lub ktoś inny prawdopodobnie zapłacę cenę za ten kupon w praktyce.

Powinienem zauważyć, że przez „konstruktor” rozumiem rzecz, którą klient wywołuje w celu zbudowania obiektu. Równie dobrze może to być coś innego niż faktyczna konstrukcja o nazwie „Konstruktor”. Na przykład coś takiego w C ++ nie naruszy zasady IMNSHO:

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>();
}

Ponieważ jedynym sposobem na utworzenie a funky_objectjest wywołaniebuild_funky zasady, aby nigdy nie dopuszczać do istnienia niepoprawnego obiektu, pozostaje nienaruszony, nawet jeśli faktyczny „Konstruktor” nie zakończy zadania.

To jednak dużo dodatkowej pracy dla wątpliwego zysku (może nawet straty). Nadal wolałbym trasę wyjątkową.

W takim przypadku użyłbym metody fabrycznej. Zasadniczo, ustaw swoją klasę tylko na prywatne konstruktory i metodę fabryczną, która zwraca instancję twojego obiektu. Jeśli początkowe parametry są niepoprawne, po prostu zwróć null i poproś kod wywołujący o podjęcie decyzji.

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;
    }
}

Nigdy nie rzucaj wyjątków, chyba że warunki są wyjątkowe. Myślę, że w tym przypadku pustą wartość można łatwo przekazać. W takim przypadku użycie tego wzorca pozwoliłoby uniknąć wyjątków i kar za wydajność, które ponoszą, przy jednoczesnym utrzymaniu prawidłowego stanu MyClass.

• Konstruktor nie powinien mieć żadnych skutków ubocznych.
  • Coś więcej niż inicjalizacja pola prywatnego powinna być postrzegana jako efekt uboczny.
  • Konstruktor z efektami ubocznymi łamie zasadę pojedynczej odpowiedzialności (SRP) i działa wbrew duchowi programowania obiektowego (OOP).
• Konstruktor powinien być lekki i nigdy nie powinien zawieść.
  • Na przykład zawsze wzdrygam się, gdy widzę blok try-catch w konstruktorze. Konstruktor nie powinien zgłaszać wyjątków ani rejestrować błędów.

Można rozsądnie zakwestionować te wytyczne i powiedzieć: „Ale nie przestrzegam tych zasad, a mój kod działa dobrze!” Na to odpowiedziałbym: „Cóż, to może być prawda, dopóki tak nie będzie”.

• Wyjątki i błędy wewnątrz konstruktora są bardzo nieoczekiwane. O ile nie zostanie im to nakazane, przyszli programiści nie będą skłonni otaczać tych wywołań konstruktora kodem obronnym.
• Jeśli coś zawiedzie w produkcji, wygenerowany ślad stosu może być trudny do przeanalizowania. Początek śledzenia stosu może wskazywać na wywołanie konstruktora, ale wiele rzeczy dzieje się w konstruktorze i może nie wskazywać na faktyczne LOC, które nie powiodło się.
  • Przetwarzałem wiele śladów stosu .NET tam, gdzie tak było.

To zależy od tego, co robi MyClass. Jeśli MyClass była w rzeczywistości klasą repozytorium danych, a tekst parametru był łańcuchem połączenia, najlepszą praktyką byłoby zgłoszenie wyjątku ArgumentException. Jeśli jednak MyClass jest klasą StringBuilder (na przykład), możesz po prostu pozostawić ją pustą.

Zależy to zatem od tego, jak istotny jest tekst parametru dla metody - czy obiekt ma sens z pustą lub pustą wartością?

Preferuję ustawienie domyślne, ale wiem, że Java ma bibliotekę „Apache Commons”, która robi coś takiego, i myślę, że to również całkiem dobry pomysł. Nie widzę problemu z zgłaszaniem wyjątku, jeśli niepoprawna wartość spowodowałaby, że obiekt byłby niezdatny do użytku; ciąg nie jest dobrym przykładem, ale co, jeśli byłby to dla DI biednego człowieka? Nie można było działać, jeśli nullzamiast ICustomerRepositoryinterfejsu powiedzmy wartość . Powiedziałbym, że w takiej sytuacji zgłoszenie wyjątku jest właściwym sposobem postępowania.

Kiedy pracowałem w c ++, nie używałem do rzucania wyjątków w konstruktorze, ponieważ może to prowadzić do wycieku pamięci, nauczyłem się tego na własnej skórze. Każdy, kto pracuje z c ++, wie, jak trudny i problematyczny może być wyciek pamięci.

Ale jeśli jesteś w języku C # / Java, nie masz tego problemu, ponieważ śmieciarz zbierze pamięć. Jeśli używasz języka C #, myślę, że lepiej jest używać właściwości w przyjemny i spójny sposób, aby upewnić się, że ograniczenia danych są gwarantowane.

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
    }
}

Zgłoszenie wyjątku będzie prawdziwym bólem dla użytkowników twojej klasy. Jeśli sprawdzanie poprawności stanowi problem, generalnie tworzę obiekt jako proces dwuetapowy.

1 - Utwórz instancję

2 - Wywołaj metodę Initialize z wynikiem zwrotu.

LUB

Wywołaj metodę / funkcję, która utworzy dla ciebie klasę, która może przeprowadzić walidację.

LUB

Miej flagę isValid, co mi się nie podoba, ale niektórzy to robią.