java - example - getters y setters realizando lógica adicional

pojo java example

Question

Tengo una clase de Java que representa la correlación entre dos elementos (POJO típico):

public class Correlation {

    private final String a;
    private final String b;

    private double correlation;

    public Correlation(String a, String b) {
        this.a = a;
        this.b = b;
    }

    public double getCorrelation() {
        return correlation;
    }

    public void setCorrelation(double correlation) {
        this.correlation = correlation;
    }

}

Para seguir la lógica de correlación correcta si a es igual a b, entonces el valor de correlación debe ser SIEMPRE 1. Podría agregar la lógica que altera el método de obtención (ignore el hecho del posible valor nulo para a):

public double getCorrelation() {
    if (a.equals(b)) {
        return 1D;
    } else {
        return correlation;
    }
}

Lo que me molesta es agregar esta lógica a un método getter, ¿debería cambiar el nombre del método o documentarlo debería considerarse suficiente?

Answer 1

Dado que la correlación es un valor "derivado" de alguna manera / a veces de a y b (es decir, es 1 si a es igual a b, pero podría calcularse de alguna manera original dependiendo de (a, b), una buena opción podría calcularse correlación en el constructor y lanzar una excepción IllegalArgumentException dentro de setCorrelation si la vara viola la lógica interna del objeto:

public class Correlation {

    private final String a;
    private final String b;

    private double correlation;

    public Correlation(String a, String b) {
        this.a = a;
        this.b = b;
        calculateCorrelation();
    }

    protected calculateCorrelation() { 
        // open to more complex correlation calculations depending on the input,
        // overriding by subclasses, etc.
        if (a.equals(b)) {
            this.correlation = 1D;
        } else {
            this.correlation = 0;
        }
    }

    public double getCorrelation() {
        return correlation;
    }

    public void setCorrelation(double correlation) throws IllegalArgumentException {
        if (a.equals(b) && correlation != 1D) {
            throw new IllegalArgumentException("Correlation must be 1 if a equals b");
        }

        this.correlation = correlation;
    }
}

Siguiendo este esquema, también podría "generar" su clase de correlación.

Answer 2

En los casos donde a! = B, ¿cómo se calcula la correlación?

Si la correlación se calcula principalmente a partir de a y b, setCorrelation () debe eliminarse. Período. La correlación debe calcularse en el constructor o en el método getCorrelation (). Uno de los principios de la POO es agrupar los datos y la lógica relacionados, por lo que el cálculo de la correlación se debería realizar idealmente en la clase que hábilmente denominó Correlation . Si el cálculo es extremadamente complicado, puede ser en otro lugar (por ejemplo, DIP), pero la llamada debe hacerse desde Correlation .

Si la correlación no se calcula a partir de a y b, realmente no entiendo la clase, por lo que "depende". Si a es igual a b, y alguien llama a setCorrelation (0.0), ¿el contrato ignorará silenciosamente la llamada y dejará la correlación en 1.0, o lanzará una excepción? Y, si estoy escribiendo el código de llamada, estoy en un dilema, ya que no sé qué pasará si trato de establecer Correlación (0.0) porque no tengo idea de qué son a y b, o si no, de todos los lugares. hacer la llamada Me veo obligado a ir if (getA().equals(getB())) etc ... o para capturar la Excepción y hacer, eh, ¿qué? Lo que viola DRY y es exactamente la razón por la que OOP dice que la lógica y los datos deben agruparse en una clase.

Answer 3

En los primeros días de Java, los pares get / set se utilizaron para identificar las propiedades de los beans exactamente con el propósito de hacer posible definir atributos conceptuales implementados a través del cálculo en lugar de una variable de miembro simple.

Desafortunadamente, con el paso del tiempo, los programadores confían cada vez más en que los que obtienen / configuran son solo los que acceden / mutan para los atributos subyacentes, una tendencia que se hizo oficial con la introducción del término POJO para identificar objetos que solo tenían captadores y posiblemente Setters como métodos.

Por otro lado, es bueno distinguir los objetos que realizan cálculos de los objetos que simplemente transportan datos; Supongo que deberías decidir qué tipo de clase deseas implementar. En su lugar, probablemente haría de la correlación un argumento de constructor adicional y verificaría su validez allí, en lugar de hacerlo en su captador. Su Correlation no puede ser un objeto computacional, ya que no tiene suficiente información para realizar ningún cálculo.

Answer 4

Los efectos secundarios en captadores y definidores generalmente no son una gran idea, ya que generalmente no se espera y pueden dar lugar a errores complicados. Sugeriría crear un método "correlate ()" o algo más que no sea específicamente un captador en este caso.

Espero que esto ayude.

Answer 5

Si estuviera usando su clase, esperaría que getCorrelation () devuelva la correlación. De hecho, probablemente rediseñaría la clase para tener el método estático correlateElements (String a, String b) que devuelve un doble.

Answer 6

Tiene más sentido imponer el valor durante setCorrelation(...) . Por ejemplo,

public void setCorrelation(double correlation) {
  if (a.equals(b)) {
    if (Math.abs(correlation - 1D) > EPSILON) {
      throw new InconsistentException(...);
    }
    this.correlation = 1D;
  } else {
    this.correlation= correlation;
  }
}

También consideraría hacer que la propiedad de correlación sea anulable, donde un null indica que aún no se ha establecido una correlación.

Answer 7

Yo diría que usar algo como getValue ()