Especificar el tipo correcto de valor para un atributo

Cada AttributeValue de CER tiene un método specifyValue para permitir que se especifique el valor del atributo (en lugar de calcularlo). El método toma cualquier valor¹, pero si especifica el tipo incorrecto de valor, CER generará un error de tiempo de ejecución:

public void incorrectValueType() {

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

    /**
     * No funcionará - retirementCause() espera una serie, no un
     * número.
     *
     * CER mostrará el mensaje: Intento de establecer el valor '123'
     * (de tipo 'java.lang.Integer') en el atributo 'retirementCause'
     * de la clase de regla 'FlexibleRetirementYear' (que espera un
     * 'java.lang.String').
     */
    flexibleRetirementYear.retirementCause().specifyValue(123);

  }

¹ Los lectores técnicos pueden preguntarse por qué AttributeValue.specifyValue no utilizan genéricos de Java 5 para restringir el tipo de valor que puede recibir.

Si una clase de regla A amplía la clase de regla B, A puede alterar temporalmente la derivación de cualquiera de los atributos de B. A también puede volver a declarar cualquiera de los atributos de B para que sean de un tipo más restrictivo (es decir, la declaración de A del atributo especifica que su tipo sea un subtipo del declarado por B).

La interfaz Java generada para A amplía la interfaz Java generada para B. Dado que los descriptores de acceso devuelven calculadoras, en lugar del tipo de valor directamente, todas las interfaces deben utilizar la extensión de comodín para que el compilador permita que la declaración de A del descriptor de acceso del atributo amplíe la de B. Dado que se utiliza la extensión comodín, specifyValue no puede restringirse a un tipo y, por lo tanto, se debe declarar para recibir cualquier objeto (Object).

Desde otro punto de vista, si una clase Java C tuviera que ampliar Java D, C puede definir un tipo de retorno más restrictivo para uno de los métodos get de D, pero no puede restringir los métodos set de D a un subtipo: C debe implementar el método de D y detectar los valores no deseados en el tiempo de ejecución (aunque al hacerlo es posible que viole de manera cuestionable el principio de sustitución de Liskov).

Otra justificación es que, cuando se utilizan los objetos de regla puramente-dinámicos (es decir, en una sesión interpretada), la restricción de tiempo de compilación de valores no se puede utilizar.

Por lo tanto, CER utiliza su conocimiento de tipos de atributo declarados para detectar valores incorrectos en el tiempo de ejecución, no el tiempo de compilación.