Spécification du type correct de valeur pour un attribut

Chaque attribut AttributeValue possède une méthode specifyValue permettant de spécifier (et non de calculer) la valeur d'attribut. La méthode accepte n'importe quelle valeur¹Si vous spécifiez le type de valeur incorrect, CER indique une erreur d'exécution :

public void incorrectValueType() {

    final FlexibleRetirementYear flexibleRetirementYear =
        FlexibleRetirementYear_Factory.getFactory().newInstance(
            session);

    /**
     * Ne fonctionne pas - retirementCause() attend une chaîne, et non pas un
     * nombre.
     *
     * CER va signaler le message : Tentative de définition de la valeur '123'
     * (de type 'java.lang.Integer') sur l'attribut 'retirementCause'
     * de la classe de règles 'FlexibleRetirementYear' (qui attend
     * 'java.lang.String').
     */
    flexibleRetirementYear.retirementCause().specifyValue(123);

  }

¹ Les lecteurs techniques peuvent se demander pourquoi l'attribut AttributeValue.specifyValue n'utilise pas de caractères génériques Java 5 pour limiter le type de valeur qu'il peut recevoir.

Si une classe de règles A étend la classe de règles B, A peut remplacer la dérivation de n'importe quel attribut B. A peut également redéclarer n'importe quel attribut B de façon plus restrictive (par ex., la déclaration A de l'attribut indique que son type est un sous-type de celui déclaré par B).

L'interface Java générée pour A étend l'interface Java générée pour B. Les manipulateurs retournant les calculateurs, et non pas directement le type de valeur, toutes les interfaces doivent utiliser une extension générique de sorte que le compilateur autorise la déclaration A du manipulateur de l'attribut à étendre celle de B. L'extension générique étant utilisée, l'attribut specifyValue ne peut pas se limiter à un type et doit par conséquent être déclaré pour recevoir un attribut Object.

D'un autre point de vue, si une classe Java C doit être étendue en classe Java D, C peut alors définir un type de retour plus restrictif pour l'une des méthodes get D, mais ne peut pas restreindre les méthodes d'accès set en un sous-type. C doit implémenter la méthode d'accès set D et détecter les valeurs non souhaitées au moment de l'exécution (bien qu'une telle pratique puisse enfreindre le principe de substitution de Liskov).

De plus, lorsque des objets règle de purement dynamiques sont utilisés (par ex., dans une session interprétée), la restriction de temps de compilation des valeurs ne peut pas être utilisée.

Par conséquent, CER utilise sa connaissance des types d'attribut déclaré pour détecter des valeurs incorrectes au moment de l'exécution, et non au moment de la compilation.