2013-06-12 8 views
8

Jestem w dylemacie. The (zredukowana) zadaniem jest przeprojektowanie danych następujących klasa posiadaczPreferowany sposób ustawiania domyślnych wartości właściwości zerowalnych?

class Stuff 
{ 
    public String SomeInfo { get; set; } 
} 

celu dostosowania popytu że zerowy nie musi być zwrócony. Mogę wymyślić dwa sposoby na osiągnięcie tego i po głębokim rozważeniu 15 minut po prostu nie mogę zdecydować, który z nich ma być preferowany.

Podejście według konstruktora.

class Stuff 
{ 
    public String SomeInfo { get; set; } 
    public Stuff() { SomeInfo = String.Empty; } 
} 

Podejście według nieruchomości.

class Stuff 
{ 
    private String _SomeInfo; 
    public String SomeInfo 
    { 
    get { return _SomeInfo ?? String.Empty; } 
    set { _SomeInfo = value; } 
    } 
} 

Zauważ, że stworzenie Rzeczy przypadkach może być wykonane za pomocą konstruktora a także inicjowania, jeśli to jakiegokolwiek znaczenia. O ile jestem poinformowany, nie będzie żadnych innych ograniczeń (ale wiesz, jak specyfikacje klientów nie zawsze odzwierciedlają rzeczywistość).

+9

Cóż - Twoja pierwsza opcja nie spełnia Twoich wymagań - ponieważ wciąż mogę ustawić właściwość na wartość null. # 2 to twój jedyny prawdziwy wybór. –

+1

Jeśli przez inicjalizację rozumiesz jakąś formę deserializacji, pamiętaj, że niektóre implementacje nie wykonają kodu konstruktora. – Rafal

+1

Innym mniejszym aromatem w punkcie 2 może być sprawdzanie danych wejściowych podczas ustawiania wartości zamiast pobierania. Jeśli zauważysz, że bardzo często pobierasz wartości 'null/Empty', zamiast tego sprawdzasz raz/rzadko, kiedy ustawienie może być preferowane. EDYCJA: Zauważ, że zakłada to, że jesteś wystarczająco czujny, aby nie ustawić pola backing na wartość null. –

Odpowiedz

17

Można jedynie zapewnić, że null nigdy nie jest zwracana w przypadku korzystania z własności:

class Stuff 
{ 
    private String _SomeInfo; 
    public String SomeInfo 
    { 
    get { return _SomeInfo ?? String.Empty; } 
    set { _SomeInfo = value; } 
    } 
} 

To samo podejście jest stosowane przez text-kontrolnych (np w ASP.NET), w którym nieruchomość Text nigdy nie powraca null ale String.Empty.

Na przykład (ILSpy):

// System.Web.UI.WebControls.TextBox 
public virtual string Text 
{ 
    get 
    { 
     string text = (string)this.ViewState["Text"]; 
     if (text != null) 
     { 
      return text; 
     } 
     return string.Empty; 
    } 
    set 
    { 
     this.ViewState["Text"] = value; 
    } 
} 
5

Można również realizować logikę w seter zamiast w getter, tamtędy plecy pole zawsze ma poprawną wartość

class Stuff 
{ 
    private String _SomeInfo = string.Empty; 
    public String SomeInfo 
    { 
    get { return _SomeInfo; } 
    set 
    { 
     if (value != null) 
     { 
     _SomeInfo = value; 
     } 
    } 
    } 
} 
+0

Możesz chcieć zaktualizować opcję 'if', aby ustawić' String.Empty' zamiast nie robić nic. Na przykład: 'myStuff.SomeInfo =" Hello! "; myStuff.SomeInfo = null; Console.WriteLine (myStuff.SomeInfo); // drukuje Hello! 'EDIT: Prawdopodobnie tak prosty jak' _someInfo = value ?? String.Empty; ' –

+0

@ChrisSinclair Myślę, że to naprawdę zależy od PO. Można również zdecydować się na wyjątek w przypadku błędu ... –

+0

+1 Zgadzam się, że jest kilka opcji. Zasugerowałem tylko, ponieważ przypisanie 'String.Empty' będzie zgodne z zachowaniem OP, które teraz demonstruje. –

4

Wystarczy Aby dodać kolejną odpowiedź, możesz także ustawić domyślną wartość obiektu tekstowego w pojedynczej instrukcji;

class Stuff 
{ 
    private String Something {get; set;} = string.Empty; 
}