Comment implémenter une propriété sur la classe A qui fait référence à une propriété d'un objet enfant de la classe A

Nous avons ce code qui, une fois simplifié, ressemble à ceci:

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

Nous avons maintenant trois points de vue.

1) Il s'agit d'un bon code car la Clientpropriété doit toujours être définie (c'est-à-dire non nulle), de sorte que la valeur Client == nullne se produira jamais et que la valeur Id 0indique un faux Id de toute façon (c'est l'opinion de l'auteur du code ;-))

2) Vous ne pouvez pas compter sur l'appelant pour savoir qu'il 0s'agit d'une valeur fausse Idet lorsque la Clientpropriété doit toujours être définie, vous devez jeter un exceptiondans la getlorsque la Clientpropriété se trouve être nulle.

3) Lorsque la Clientpropriété doit toujours être définie, il vous suffit de revenir Client.Idet de laisser le code lever une NullRefexception lorsque la Clientpropriété est nulle.

Laquelle de ces réponses est la plus correcte? Ou existe-t-il une quatrième possibilité?

Cela sent que vous devriez limiter le nombre d'états dans lesquels votre Roomclasse peut être.

Le fait même que vous vous demandiez quoi faire quand Clientest nul est un indice que Rooml'espace d'état est trop grand.

Pour garder les choses simples, je n'autoriserais jamais la Clientpropriété d'une Roominstance à être nulle. Cela signifie que le code qu'il contient Roompeut sans risque supposer que le Clientn'est jamais nul.

Si pour une raison quelconque dans l'avenir Clientdevient nullrésister à l'envie de soutenir cet état. Cela augmentera la complexité de votre maintenance.

Au lieu de cela, laissez le code échouer et échouer rapidement. Après tout, ce n'est pas un état pris en charge. Si l'application se met dans cet état, vous avez déjà franchi une ligne de non-retour. La seule chose raisonnable à faire est alors de fermer l'application.

Cela peut se produire (tout naturellement) à la suite d'une exception de référence nulle non gérée.

Quelques considérations:

a) Pourquoi existe-t-il un getter spécifiquement pour ClientId alors qu'il existe déjà un getter public pour l'instance Client elle-même? Je ne vois pas pourquoi les informations sur le ClientId longdoivent être gravées dans la pierre dans la signature de Room.

b) Concernant le deuxième avis, vous pourriez introduire une constante Invalid_Client_Id.

c) Concernant les opinions un et trois (et étant mon point principal): Une chambre doit toujours avoir un client? C'est peut-être juste de la sémantique mais cela ne sonne pas bien. Il serait peut-être plus approprié d'avoir des classes complètement séparées pour la chambre et le client et une autre classe qui les relie. Peut-être rendez-vous, réservation, occupation? (Cela dépend de ce que vous faites réellement.) Et sur cette classe, vous pouvez appliquer les contraintes "doit avoir une salle" et "doit avoir un client".

Je ne suis pas d'accord avec les trois opinions. Si Clientcela ne peut jamais arriver null, alors ne le permettez même pasnull !

1. Définissez la valeur de Clientdans le constructeur
2. Jetez un ArgumentNullExceptiondans le constructeur.

Donc, votre code serait quelque chose comme:

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

Ceci n'est pas lié à votre code, mais vous feriez probablement mieux d'utiliser une version immuable de Roomen créant theClient readonly, puis si le client change, en créant une nouvelle salle. Cela améliorera la sécurité des threads de votre code en plus de la sécurité nulle des autres aspects de ma réponse. Voir cette discussion sur mutable vs immuable

Les deuxième et troisième options doivent être évitées - le getter ne doit pas frapper l'appelant à une exception qu'il n'a aucun contrôle.

Vous devez décider si le client peut être nul. Si tel est le cas, vous devez fournir à l'appelant un moyen de vérifier s'il est nul avant d'y accéder (par exemple, la propriété bool ClientIsNull).

Si vous décidez que le client ne peut jamais être nul, faites-en un paramètre obligatoire pour le constructeur et lancez-y l'exception si un null est passé.

Enfin, la première option contient également une odeur de code. Vous devez laisser le client gérer sa propre propriété d'identification. Il semble exagéré de coder un getter dans une classe conteneur qui appelle simplement un getter sur la classe contenue. Exposez simplement le client en tant que propriété (sinon, vous finirez par dupliquer tout ce qu'un client offre déjà ).

long clientId = room.Client.Id;

Si le client peut être nul, vous allez au moins donner la responsabilité à l'appelant:

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

Si une propriété Client nulle est un état pris en charge, envisagez d'utiliser un objet NullObject .

Mais très probablement, c'est un état exceptionnel, vous devriez donc rendre impossible (ou tout simplement pas très pratique) de se retrouver avec un null 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;
}

S'il n'est pas pris en charge cependant, ne perdez pas de temps sur des solutions à moitié cuites. Dans ce cas:

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

Vous avez "résolu" l'exception NullReferenceException ici, mais à un coût élevé! Cela forcerait tous les appelants Room.ClientIdà vérifier 0:

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

Des bogues étranges peuvent survenir avec d'autres développeurs (ou vous-même!) En oubliant de vérifier la valeur de retour "ErrorCode" à un moment donné.
Jouez en toute sécurité et échouez rapidement. Autoriser la levée de l'exception NullReferenceException et l'attraper "gracieusement" quelque part plus haut dans la pile des appels au lieu de permettre à l'appelant de gâcher encore plus les choses ...

Sur une note différente, si vous êtes si désireux d'exposer le Clientet aussi de ClientIdpenser à TellDontAsk . Si vous en demandez trop aux objets au lieu de leur dire ce que vous voulez réaliser, vous pouvez mettre fin à tout coupler ensemble, ce qui rendra le changement plus difficile plus tard.

À partir de c # 6.0, qui est maintenant disponible, vous devez simplement le faire,

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

Élever une propriété de Clientto Roomest une violation évidente de l'encapsulation et du principe DRY.

Si vous devez accéder à l' Idun Clientdes éléments que Roomvous pouvez faire,

var clientId = room.Client?.Id;

Notez que l'utilisation de l' opérateur conditionnel Null , clientIdsera un long?, si Clientest null, clientIdsera null, sinon clientIdaura la valeur de Client.Id.