Como implementar uma propriedade na classe A que se refere a uma propriedade de um objeto filho da classe A

Temos este código que, quando simplificado, fica assim:

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

Agora temos três pontos de vista.

1) Este é um bom código porque a Clientpropriedade deve sempre ser configurada (ou seja, não nula), para Client == nullque nunca ocorra e o valor do Id 0denote um ID falso de qualquer maneira (essa é a opinião do autor do código ;-))

2) Você não pode confiar no chamador para saber que 0é um valor falso para Ide quando a Clientpropriedade sempre deve ser definida, você deve lançar um exceptionno getquando a Clientpropriedade for nula

3) Quando a Clientpropriedade sempre deve ser definida, basta retornar Client.Ide deixar o código lançar uma NullRefexceção quando a Clientpropriedade for nula.

Qual destes está mais correto? Ou existe uma quarta possibilidade?

Parece que você deve limitar o número de estados em que sua Roomclasse pode estar.

O fato de você estar perguntando sobre o que fazer quando Clienté nulo é uma dica de que Roomo espaço de estado é muito grande.

Para simplificar, não permitiria que a Clientpropriedade de nenhuma Roominstância fosse nula. Isso significa que o código dentro Roompode assumir com segurança que Clientnunca é nulo.

Se por algum motivo no futuro Clienttorna-se nullresistir ao desejo de apoiar esse estado. Fazer isso aumentará sua complexidade de manutenção.

Em vez disso, permita que o código falhe e falhe rapidamente. Afinal, este não é um estado suportado. Se o aplicativo entrar nesse estado, você já cruzou uma linha sem retorno. A única coisa razoável a fazer é fechar o aplicativo.

Isso pode acontecer (naturalmente) como resultado de uma exceção de referência nula não tratada.

Apenas algumas considerações:

a) Por que existe um getter específico para o ClientId quando já existe um getter público para a própria instância do Client? Não vejo por que as informações do ClientId precisam longser gravadas em pedra na assinatura do Room.

b) Em relação à segunda opinião, você pode introduzir uma constante Invalid_Client_Id.

c) Em relação à opinião um e três (e sendo meu ponto principal): Uma sala deve sempre ter um cliente? Talvez seja apenas semântica, mas isso não parece certo. Talvez seja mais apropriado ter classes completamente separadas para Room e Client e outra classe que as una. Talvez nomeação, reserva, ocupação? (Isso depende do que você está realmente fazendo.) E nessa classe, você pode impor as restrições "deve ter uma sala" e "deve ter um cliente".

Não concordo com as três opiniões. Se Clientnunca pode ser null, nem torne possível que sejanull !

1. Defina o valor de Clientno construtor
2. Jogue um ArgumentNullExceptionno construtor.

Portanto, seu código seria algo como:

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

Isso não tem relação com o seu código, mas você provavelmente usaria uma versão imutável de Roommaking theClient readonly, e se o cliente mudar, criando uma nova sala. Isso melhorará a segurança do encadeamento do seu código, além da segurança nula dos outros aspectos da minha resposta. Veja esta discussão sobre mutável vs imutável

As segunda e terceira opções devem ser evitadas - o atendente não deve bater no chamador com uma exceção sobre a qual eles não têm controle.

Você deve decidir se o Cliente pode ser nulo. Nesse caso, você deve fornecer uma maneira para um chamador verificar se é nulo antes de acessá-lo (por exemplo, propriedade booleana ClientIsNull).

Se você decidir que o Cliente nunca pode ser nulo, torne-o um parâmetro obrigatório para o construtor e lance a exceção se um nulo for passado.

Finalmente, a primeira opção também contém um cheiro de código. Você deve deixar o Cliente lidar com sua própria propriedade de ID. Parece um exagero codificar um getter em uma classe de contêiner que simplesmente chama um getter na classe contida. Apenas exponha o cliente como uma propriedade (caso contrário, você duplicará tudo o que o cliente já oferece ).

long clientId = room.Client.Id;

Se o Cliente puder ser nulo, você pelo menos dará responsabilidade ao chamador:

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

Se uma propriedade nula do cliente for um estado suportado, considere usar um NullObject .

Mas, provavelmente, esse é um estado excepcional, portanto, você deve tornar impossível (ou não muito conveniente) acabar com um valor nulo 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;
}

Se não for suportado, no entanto, não perca tempo com soluções meio cozidas. Nesse caso:

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

Você 'resolveu' a NullReferenceException aqui, mas a um grande custo! Isso forçaria todos os chamadores de Room.ClientIda verificarem 0:

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

Bugs estranhos podem surgir com outros desenvolvedores (ou você mesmo!) Esquecendo de verificar o valor de retorno "ErrorCode" em algum momento.
Jogue pelo seguro e falhe rápido. Permita que a NullReferenceException seja lançada e "graciosamente" a pegue em algum lugar mais alto na pilha de chamadas, em vez de permitir que o chamador estrague ainda mais as coisas ...

Em outra nota, se você deseja expor o Cliente também ClientIdpensar sobre o TellDontAsk . Se você pedir demais aos objetos, em vez de dizer a eles o que deseja alcançar, poderá acabar acoplando tudo, dificultando as mudanças mais tarde.

A partir do c # 6.0, agora lançado, você deve fazer isso,

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

Criar uma propriedade de Clientto Roomé uma violação óbvia do encapsulamento e do princípio DRY.

Se você precisar acessar o Idde um Clientde um, Roomvocê pode fazer,

var clientId = room.Client?.Id;

Observe o uso do operador condicional nulo , clientIdserá um long?, se Clienté null, clientIdserá null, caso contrário clientIdterá o valor de Client.Id.