Opcje inicjalizacji obiektu C#

Question

Nie inicjalizuje obiektu poza hermetyzacją przerwań konstruktora?

Dane:

class MyClass 
{ 
    public string _aString; 
} 

nie powinien być członkiem _aString prywatne i instancji poprzez wywołanie konstruktora (konstruktora tu pominąć):

MyClass test = new MyClass("test"); 

zamiast alternatywnej metody inicjalizacji obiektu :

MyClass test = new MyClass { _aString = "Test" }; 

Answer 1

"Czy inicjowanie obiektu nie jest poza hermetyzacją konstruktora?"

No nie. Jak słusznie zauważyłeś, możesz inicjować tylko właściwości, które są już dostępne w twoim bieżącym zasięgu. (publiczny, wewnętrzny itp.)

Ten rodzaj Intializacji to tak naprawdę tylko cukier syntaktyczny wokół budowy klasy i przypisywania wartości do właściwości, Jest to bardzo użyteczne w przypadku klas Anonymous i klauzul wyboru Linq.

Answer 2

Zazwyczaj uważa się za złą praktykę W niektórych przypadkach może być do przyjęcia, na przykład jeśli pole jest oznaczone jako readonly (co oznacza, że ​​musi być ustawione w konstruktorze). Zamiast tego, należy uczynić to pole prywatne i wystawiać go przez nieruchomości, które mogą lub nie mogą być tylko do odczytu, w zależności od jej przeznaczenia:

class MyClass 
{ 
    private string _aString; 
    public string AString 
    { 
     get { return _aString; } 
     // uncomment to make the property writable 
     //set { _aString = value; } 
    } 
} 

Answer 3

To zależy od celu zmiennej. Jeśli programista powinien mieć możliwość ustawienia zmiennej tylko podczas inicjalizacji, ale potem nie będzie miał do niej dostępu po tym czasie, to skorzystam ze zmiennej prywatnej. Jeśli chcesz, aby użytkownik klasy mógł ustawić/odczytać zmienną w dowolnym momencie, upublicznij ją.

Answer 4

Kiedy masz
public string _aString;
to naprawdę nie ma znaczenia, kiedy zainicjować tę wartość, ponieważ jest to już odsłonięta. Tak więc, gdy chcemy mówić o inicjalizacji, powinniśmy przenieść ten ciąg do właściwości. Opowiadanie o enkapsutlacji ma sens.
Wyobraźmy sobie, że mamy jakiś ciąg. Istnieją dwa główne podejścia do inicjalizacji. Jedną z nich jest wykonanie wewnątrz konstruktora, druga to leniwy inicjowanie (inicjowanie, gdy niektóre żądają tych danych).

Answer 5

Tak, zainicjuj za pomocą konstruktora i dodaj właściwości, aby zezwolić (lub nie) na dostęp do danych.

class MyClass { 
private string _aString; 
string MyProperty { 
        get { return this._aString; } 
        // you can make this private or protected 
        set { this._aString = value; } 

        } 
} 

Answer 6

Jeśli wziąć pod uwagę właściwości jak pobierające i ustawiające, nie wierzę, będzie przerwa enkapsulacji. Ale powinieneś zauważyć, że nie korzystałeś z właściwości, użyłeś zmiennej instancji. W rzeczywistości nie sądzę, żeby to działało jak twój przykład. Sprawdź to:

class MyClass { 
    private string aString; 

    public string AString { 
     get { return aString; } 
     set {aString = value; } 
    } 
} 
MyClass test = new MyClass { 
    AString = "test" 
}; 

W tym przypadku uzyskujesz dostęp do prywatnego pola przez jego akcesor. To tak, jak przy użyciu konstruktora bez parametrów i późniejszego ustawienia wartości.

Answer 7

Jeśli pytasz, czy stenogram inicjalizacji nowego obiektu łamie enkapsulację, to odpowiedź brzmi "nie". Możesz ustawić tylko publicznie o ograniczonym zasięgu członków nową metodą.

MyClass test = new MyClass { _aString = "Test" }; 

jest taka sama jak

MyClass test = new MyClass(); 
test._aString = "Test"; 

Answer 8

pokazać publiczny obiekt w klasie C# nie łamie „obudowania” z punktu widzenia „Programowanie obiektowe”.

Z punktu widzenia "dobrej praktyki" nie jest to dobre, należy użyć właściwości, ponieważ pozwala na zewnętrzny kod do korzystania z tej klasy, jeśli zmieni się zachowanie aktualizacji tej wartości (sprawdzanie, ...).