Polymorphic Rants

Da tempo cerco di evitare che qualsiasi field di un oggetto sia a null, o implementando il null pattern o aggiungendo delle constraint ai costruttori ed ai metodi in modo che non ci possano essere dei riferimenti a null in tutto il ciclo di vita di un oggetto. Questo rende il codice estremamente pulito, meno error prone e ti costringe a lavorare in in modalità “cervello enabled” ([TM] ), cioè devi sempre cercare di capire come e quando può servire una constraint.

Prendiamo questa classe:

class Person {
private String name;
public void Person (String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
}

La classe non ha alcuna constraint, nè nel costruttore ne tantomeno nell’accessor. Ora però, abbiamo bisogno di implementare il metdo equals:

public boolean equals(Object object) {
if (object == null || !(object instanceof Person) ) {
return false;
}
Person otherPerson = (Person) object;
if ( (object.name == null && otherPerson.name == null) || (object.name != null && object.name.equals(otherPerson.name) ) {
return true;
} else {
return false;
}

Terribile!!! La possibilità che name sia null costringe a testare due condizioni in più in equals!!! Se avessimo definito delle constraint su name per evitare che sia null, il controllo di uguaglianza sarebbe semplicemente stato:

public boolean equals(Object object) {
[...] return object.name.equals(otherPerson.name);
}

La ricetta della nonna quindi prevede:

• null pattern dove possibile (e sensato)
• constraint: testare i parametri del costruttore e dei metodi ed eventualmente lanciare una IllegalArgumentException se sono null
• istanziare tutti gli oggetti nel costruttore, non aspettare di farlo in qualche altro metodo

Tags: pattern, Java, good practices