Partage de cas de code pour la construction et la vérification d'objets Java et Ceylan

Lors de la conversion de code Java en code Ceylan, je rencontre parfois des situations où certains constructeurs de classes Java confondent validation et initialisation. Utilisons un exemple de code simple mais artificiel pour illustrer ce que je veux dire.

Un mauvais code

Considérez la classe Java suivante. (Mec, n'écris pas de code comme ça à la maison)

public class Period {
    private final Date startDate;
    private final Date endDate;
    //returns null if the given String
    //does not represent a valid Date
    private Date parseDate(String date) {
       ...
    }
    public Period(String start, String end) {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public boolean isValid() {
        return startDate!=null && endDate!=null;
    }
    public Date getStartDate() {
        if (startDate==null) 
            throw new IllegalStateException();
        return startDate;
    }
    public Date getEndDate() {
        if (endDate==null)
            throw new IllegalStateException();
        return endDate;
    }
}

Hé, je l'ai déjà prévenu, c'est artificiel. Cependant, il n'est pas rare de trouver quelque chose comme ça dans du vrai code Java.

Le problème ici est que même si la validation du paramètre d'entrée (dans la méthode cachée parseDate()) échoue, nous obtenons toujours une instance de Period. Mais la Période que nous avons obtenue n'est pas un état "valide". À proprement parler, qu’est-ce que je veux dire ?

Eh bien, je dirais qu'un objet est dans un état inactif s'il ne peut pas répondre de manière significative aux opérations courantes. Dans cet exemple, getStartDate() et getEndDate() lanceront une IllegalStateException, ce qui est une situation que je ne pense pas « significative ».

En regardant cet exemple de l'autre côté, lors de la conception de Period, nous avons une panne de type sécurité. Les exceptions non cochées représentent un « trou » dans le système de types. Par conséquent, une meilleure conception de type sécurisé pour Period serait une conception qui n'utilise pas d'exceptions non vérifiées, ce qui dans ce cas signifie ne pas lancer d'exception IllegalStateException.

(En fait, dans le code réel, je suis plus susceptible de rencontrer une méthode getStartDate() qui ne vérifie pas null, ce qui entraîne une NullPointerException après cette ligne de code, ce qui est encore pire.)

Nous pouvons facilement convertir la classe Period ci-dessus en une classe de style Ceylan :

shared class Period(String start, String end) {
    //returns null if the given String
    //does not represent a valid Date
    Date? parseDate(String date) => ... ;
    value maybeStartDate = parseDate(start);
    value maybeEndDate = parseDate(end);
    shared Boolean valid
        => maybeStartDate exists 
        && maybeEndDate exists;
    shared Date startDate {
        assert (exists maybeStartDate);
        return maybeStartDate;
    }
    shared Date endDate {
        assert (exists maybeEndDate);
        return maybeEndDate;
    }
}

Bien sûr, ce code rencontrera également les mêmes problèmes que le code Java original. Les deux symboles d'assertion nous signalent qu'il y a un problème dans la sécurité du type du code.

Améliorer le code Java

Comment pouvons-nous améliorer ce code en Java ? Eh bien, voici un exemple dans lequel les exceptions vérifiées tant décriées de Java peuvent être une solution très raisonnable ! Nous pouvons légèrement modifier Period pour lever une exception vérifiée depuis son constructeur :

public class Period {
    private final Date startDate;
    private final Date endDate;
    //throws if the given String
    //does not represent a valid Date
    private Date parseDate(String date)
            throws DateFormatException {
       ...
    }
    public Period(String start, String end) 
            throws DateFormatException {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public Date getStartDate() {
        return startDate;
    }
    public Date getEndDate() {
        return endDate;
    }
}

Désormais, avec cette solution, nous n'obtiendrons pas de Period dans un état inactif, le code qui instancie Period sera responsable de gérer les situations d'entrée non valides par le compilateur, qui interceptera une exception DateFormatException.

try {
    Period p = new Period(start, end);
    ...
}
catch (DateFormatException dfe) {
    ...
}

Il s'agit d'une utilisation agréable, parfaite et correcte des exceptions vérifiées, malheureusement je vois rarement du code Java utilisant des exceptions vérifiées comme ci-dessus.

Améliorer le code de Ceylan

Alors qu'en est-il de Ceylan ? Ceylan n’a pas d’exceptions vérifiées, nous devons donc trouver une solution différente. Généralement, dans les situations où l'appel d'une fonction en Java lèverait une exception vérifiée, Ceylan appellerait la fonction et renverrait un type d'union. Étant donné qu'un initialiseur de classe ne renvoie aucun type autre que la classe elle-même, nous devons extraire une logique mixte d'initialisation/validation dans une fonction d'usine.

//returns DateFormatError if the given 
//String does not represent a valid Date
Date|DateFormatError parseDate(String date) => ... ;
shared Period|DateFormatError parsePeriod
        (String start, String end) {
    value startDate = parseDate(start);
    if (is DateFormatError startDate) {
        return startDate;
    }
    value endDate = parseDate(end);
    if (is DateFormatError endDate)  {
        return endDate;
    }
    return Period(startDate, endDate);
}
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

Selon le système de types, l'appelant est obligé de gérer DateFormatError :

value p = parsePeriod(start, end);
if (is DateFormatError p) {
    ...
}
else {
    ...
}

Alternativement, si nous ne nous soucions pas du problème réel d'un format de date donné ( ce qui est possible, en supposant que notre code d'initialisation fonctionnel manque cette information), nous pouvons utiliser Null au lieu de DateFormatError :

//returns null if the given String 
//does not represent a valid Date
Date? parseDate(String date) => ... ;
shared Period? parsePeriod(String start, String end)
    => if (exists startDate = parseDate(start), 
           exists endDate = parseDate(end))
       then Period(startDate, endDate)
       else null;
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

L'approche de la fonction d'usine est pour le moins excellente, car en général lors de la validation logique et il a une meilleure isolation entre les initialisations d'objets. Ceci est particulièrement utile à Ceylan, où le compilateur ajoute des restrictions très strictes sur la logique d'initialisation des objets pour garantir que tous les champs d'un objet ne sont attribués qu'une seule fois.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!