Как реализовать свойство класса A, которое ссылается на свойство дочернего объекта класса A

У нас есть этот код, который при упрощении выглядит следующим образом:

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

Теперь у нас есть три точки зрения.

1) Это хороший код, потому что Clientсвойство всегда должно быть установлено (т. Е. Не равно нулю), чтобы Client == nullникогда не происходило, и значение 0Id в любом случае обозначает ложный Id (это мнение автора кода ;-))

2) Вы не можете полагаться на то, что вызывающая сторона знает, что 0это ложное значение, Idи когда Clientсвойство всегда должно быть установлено, вы должны бросить exceptionв, getкогда Clientсвойство оказывается пустым

3) Когда Clientсвойство всегда должно быть установлено, вы просто возвращаетесь Client.Idи позволяете коду генерировать NullRefисключение, когда Clientсвойство оказывается пустым.

Что из этого является наиболее правильным? Или есть четвертая возможность?

Пахнет, как будто вы должны ограничить количество состояний, в которых Roomможет быть ваш класс.

Тот факт, что вы спрашиваете о том, что делать, когда значение Clientравно нулю, указывает на то, что Roomпространство состояний слишком велико.

Для простоты я бы не допустил, чтобы Clientсвойство любого Roomэкземпляра когда-либо было нулевым. Это означает, что код внутри Roomможет смело предполагать, что Clientникогда не является нулевым.

Если по каким-то причинам в будущем Clientстанет nullсопротивляться желание поддержать это государство. Это увеличит сложность обслуживания.

Вместо этого позвольте коду терпеть неудачу и терпеть неудачу быстро. В конце концов, это не поддерживаемое состояние. Если приложение переходит в это состояние, вы уже переступили черту невозврата. Единственное разумное, что можно сделать, - закрыть приложение.

Это может произойти (вполне естественно) в результате необработанного исключения нулевой ссылки.

Всего несколько соображений:

а) Почему существует геттер специально для ClientId, когда уже есть публичный геттер для самого экземпляра клиента? Я не понимаю, почему информация о ClientId longдолжна быть высечена в камне в подписи Room.

б) Что касается второго мнения, вы можете ввести константу Invalid_Client_Id.

в) Относительно первого и третьего мнения (и, будучи моим главным пунктом): в комнате всегда должен быть клиент? Может быть, это просто семантика, но это звучит неправильно. Возможно, было бы более уместно иметь совершенно отдельные классы для Room и Client и другой класс, который связывает их вместе. Может быть, назначение, бронирование, размещение? (Это зависит от того, что вы на самом деле делаете.) И в этом классе вы можете применить ограничения «должна быть комната» и «должен быть клиент».

Я не согласен со всеми тремя мнениями. Если Clientникогда не может быть null, тогда даже не позволяйте этому бытьnull !

1. Установите значение Clientв конструкторе
2. Киньте ArgumentNullExceptionв конструктор.

Таким образом, ваш код будет выглядеть примерно так:

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

Это не связано с вашим кодом, но вам, вероятно, было бы лучше использовать неизменную версию Room, сделав theClient readonly, а затем, если клиент изменился, создать новую комнату. Это улучшит безопасность потока вашего кода в дополнение к нулевой безопасности других аспектов моего ответа. Смотрите это обсуждение мутабельных против неизменных

Следует избегать второго и третьего вариантов - получатель не должен шлепать вызывающего, за исключением того, что он не контролирует его.

Вы должны решить, может ли Клиент быть нулевым. Если это так, вы должны предоставить вызывающей стороне способ проверить, является ли он пустым, прежде чем получить к нему доступ (например, свойство bool ClientIsNull).

Если вы решите, что Client никогда не может иметь значение null, то сделайте его обязательным параметром для конструктора и добавьте туда исключение, если в него передан null.

Наконец, первый вариант также содержит запах кода. Вы должны позволить Клиенту иметь дело со своим собственным идентификатором. Это кажется излишним - кодировать метод получения в классе контейнера, который просто вызывает метод получения в содержащемся классе. Просто представьте Клиента как свойство (в противном случае вы в конечном итоге продублируете все, что Клиент уже предлагает ).

long clientId = room.Client.Id;

Если Client может быть нулевым, то вы по крайней мере возьмете ответственность перед вызывающей стороной:

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

Если нулевое свойство Client является поддерживаемым состоянием, рассмотрите возможность использования NullObject .

Но, скорее всего, это исключительное состояние, поэтому вы должны сделать невозможным (или просто не очень удобным) получить нулевое значение 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;
}

Однако, если это не поддерживается, не тратьте время на полуобжаренные растворы. В этом случае:

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

Вы «решили» исключение NullReferenceException здесь, но по высокой цене! Это заставит всех абонентов Room.ClientIdпроверять наличие 0:

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

Странные ошибки могут возникать из-за того, что другие разработчики (или вы сами!) Забывают проверить возвращаемое значение ErrorCode в какой-то момент времени.
Играйте безопасно и быстро. Позвольте выбрасывать исключение NullReferenceException и "изящно" перехватывать его где-то выше в стеке вызовов, вместо того, чтобы вызывающий мог все испортить еще больше ...

С другой стороны, если вы так заинтересованы, чтобы показать, Clientа также ClientIdподумать о TellDontAsk . Если вы попросите у объектов слишком много, вместо того, чтобы сказать им, чего вы хотите достичь, вы можете прекратить объединять все вместе, что усложнит изменения в дальнейшем.

Начиная с c # 6.0, который сейчас выпущен, вы должны просто сделать это,

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

Повышение свойства Clientto Roomявляется очевидным нарушением инкапсуляции и принципа DRY.

Если вам необходимо получить доступ к Idиз Clientиз Roomвы можете сделать,

var clientId = room.Client?.Id;

Обратите внимание на использование Null условного оператора , clientIdбудет long?, если Clientесть null, clientIdбудет null, в противном случае clientIdбудет иметь значение Client.Id.