Jak zaimplementować właściwość w klasie A, która odnosi się do właściwości obiektu potomnego klasy A.

Mamy ten kod, który po uproszczeniu wygląda następująco:

public class Room
{
    public Client Client { get; set; }

    public long ClientId
    {
        get
        {
            return Client == null ? 0 : Client.Id;
        }
    }
}

public class Client 
{
    public long Id { get; set; }
}

Teraz mamy trzy punkty widzenia.

1) To jest dobry kod, ponieważ Clientwłaściwość powinna być zawsze ustawiona (tj. Nie pusta), więc Client == nullnigdy się nie pojawi, a wartość 0Id i tak oznacza fałszywy identyfikator (taka jest opinia autora kodu ;-))

2) Nie można powoływać się na rozmówcy, aby wiedzieć, że 0jest fałszywa wartość Id, a gdy Clientnieruchomość powinna być zawsze należy rzucać exceptionw getgdy Clientnieruchomość zdarza się być null

3) Gdy Clientwłaściwość powinna być zawsze ustawiona, po prostu powracasz Client.Idi pozwalasz kodowi zgłosić NullRefwyjątek, gdy Clientwłaściwość jest zerowa.

Który z nich jest najbardziej poprawny? Czy jest czwarta możliwość?

Pachnie, że powinieneś ograniczyć liczbę stanów, w których Roommoże znajdować się klasa.

Sam fakt, że pytasz o to, co zrobić, gdy Clientjest pusty, jest wskazówką, że Roomprzestrzeń stanu jest zbyt duża.

Aby uprościć sprawę, nie pozwoliłbym, aby Clientwłasność jakiejkolwiek Roominstancji była zawsze pusta. Oznacza to, że kod wewnątrz Roommoże bezpiecznie założyć, że Clientnigdy nie jest zerowy.

Jeśli z jakiegoś powodu w przyszłości Clientstanie nulloprzeć się pokusie, aby wspierać ten stan. Takie postępowanie zwiększy złożoność konserwacji.

Zamiast tego pozwól, aby kod zawiódł i szybko zawiódł. W końcu nie jest to obsługiwany stan. Jeśli aplikacja przejdzie w ten stan, przekroczyłeś już linię bez powrotu. Jedyną rozsądną rzeczą do zrobienia jest zamknięcie aplikacji.

Może się to zdarzyć (całkiem naturalnie) w wyniku nieobsługiwanego wyjątku odwołania zerowego.

Kilka uwag:

a) Dlaczego istnieje getter specjalnie dla ClientId, skoro już istnieje publiczny getter dla samej instancji Client? Nie rozumiem, dlaczego informacja, że ​​ClientId jest, longmusi być wyryta w kamieniu w podpisie Pokoju.

b) Jeśli chodzi o drugą opinię, możesz wprowadzić stałą Invalid_Client_Id.

c) Jeśli chodzi o opinię pierwszą i trzecią (i co jest moim głównym punktem): pokój musi zawsze mieć klienta? Może to tylko semantyka, ale to nie brzmi dobrze. Być może bardziej odpowiednie byłoby posiadanie całkowicie oddzielnych klas dla Pokoju i Klienta oraz innej klasy, która je łączy. Może spotkanie, rezerwacja, obłożenie? (Zależy to od tego, co faktycznie robisz.) I na tej klasie możesz egzekwować ograniczenia „musi mieć pokój” i „musi mieć klienta”.

Nie zgadzam się ze wszystkimi trzema opiniami. Jeśli Clientnigdy nie może być null, to nawet nie pozwól, aby tak byłonull !

1. Ustaw wartość Clientkonstruktora
2. Wrzuć ArgumentNullExceptiondo konstruktora.

Więc twój kod byłby mniej więcej taki:

public class Room
{
    private Client theClient;

    public Room(Client client) {
        if(client == null) throw new ArgumentNullException();
        this.theClient = client;
    }

    public Client Client { 
        get { return theClient; }
        set 
        {
            if (value == null) 
                throw new ArgumentNullException();
            theClient = value;
        }
    }

    public long ClientId
    {
        get
        {
            return theClient.Id;
        }
    }
}

public class Client 
{
    public long Id { get; set; }
}

Nie ma to związku z twoim kodem, ale prawdopodobnie lepiej byłoby użyć niezmiennej wersji Room, robiąc theClient readonly, a następnie, jeśli klient się zmieni, tworząc nowy pokój. Zwiększy to bezpieczeństwo wątków w kodzie oprócz bezpieczeństwa zerowego innych aspektów mojej odpowiedzi. Zobacz tę dyskusję na temat zmiennych i niezmiennych

Należy unikać drugiej i trzeciej opcji - pobierający nie powinien uderzać dzwoniącego, z wyjątkiem tego, że nie ma nad nimi kontroli.

Powinieneś zdecydować, czy Klient może być kiedykolwiek zerowy. Jeśli tak, powinieneś umożliwić dzwoniącemu sprawdzenie, czy ma on wartość NULL, zanim uzyska do niego dostęp (np. Właściwość bool ClientIsNull).

Jeśli zdecydujesz, że Klient nigdy nie może mieć wartości NULL, ustaw go jako wymagany parametr dla konstruktora i wyślij tam wyjątek, jeśli zostanie przekazane NULL.

Wreszcie pierwsza opcja zawiera także zapach kodu. Powinieneś pozwolić Klientowi postępować z jego własną własnością ID. Wydaje się, że przesada koduje moduł pobierający w klasie kontenera, który po prostu wywołuje moduł pobierający w klasie zawartej. Po prostu ujawnij klienta jako właściwość (w przeciwnym razie skończysz duplikowaniem wszystkiego, co klient już oferuje ).

long clientId = room.Client.Id;

Jeśli Klient może mieć wartość zerową, wówczas przynajmniej ponosisz odpowiedzialność za dzwoniącego:

if (room.Client != null){
    long clientId = room.Client.Id;
    /* other code follows... */
}

Jeśli właściwość null Client jest obsługiwanym stanem, rozważ użycie NullObject .

Ale najprawdopodobniej jest to wyjątkowy stan, więc powinieneś uniemożliwić (lub po prostu nie bardzo wygodne) skończyć na zero Client:

public Client Client { get; private set; }

public Room(Client client)
{
    Client = client;
}

public void SetClient(Client client)
{
    if (client == null) throw new ArgumentNullException();
    Client = client;
}

Jeśli nie jest to obsługiwane, nie trać czasu na półpieczone roztwory. W tym przypadku:

return Client == null ? 0 : Client.Id;

„Rozwiązałeś” wyjątek NullReferenceEx tutaj, ale za wielką cenę! Zmusiłoby to wszystkich dzwoniących Room.ClientIddo sprawdzenia 0:

var aRoom = new Room(aClient);
var clientId = aRoom.ClientId;
if (clientId == 0) RestartRoombookingWizard();
else ContinueRoombooking(clientid);

Dziwne błędy mogą powstać w przypadku innych programistów (lub ciebie!), Zapominając o sprawdzeniu wartości zwracanej „ErrorCode” w pewnym momencie.
Graj bezpiecznie i szybko się nie powiedzie. Zezwól na zgłoszenie wyjątku NullReferenceException i „z wdziękiem” złap go gdzieś wyżej na stosie wywołań, zamiast pozwolić dzwoniącemu na jeszcze większy bałagan…

Z drugiej strony, jeśli tak bardzo chcesz ujawnić, Clienta także ClientIdpomyśleć o TellDontAsk . Jeśli poprosisz zbyt wiele o przedmioty zamiast powiedzieć im, co chcesz osiągnąć, możesz zakończyć łączenie wszystkiego, co utrudni później zmianę.

Począwszy od wersji c # 6.0, która jest już wydana, powinieneś to zrobić,

public class Room
{
    public Room(Client client)
    {
        this.Client = client;
    }

    public Client Client { get; }
}

public class Client
{
    public Client(long id)
    {
        this.Id = id;
    }

    public long Id { get; }
}

Podnoszenie własności Clientdo Roomjest oczywistym naruszeniem enkapsulacji i zasady DRY.

Jeśli chcesz uzyskać dostęp do Idjednego Clientz Roomnich,

var clientId = room.Client?.Id;

Uwaga korzystanie z Null Operator warunkowy , clientIdbędzie long?, jeśli Clientjest null, clientIdbędzie null, w przeciwnym razie clientIdbędzie miał wartość Client.Id.