Ho preso un dominio semplice, quello degli interi positivi dotati di somma e sottrazione, e ne ho fatto una classe.
Il costruttore non accetta numeri negativi e dunque solleva una eccezione (runtime, per semplicità):
public Natural(int value) {
if (value<0) {
throw new RuntimeException("non vale il negativo");
this.value=value;
}
}
(In alternativa si sarebbe potuto ottenere, in congiunzione con un framework di design by contract, lo stesso effetto dell'eccezione per valori negativi, tramite una precondizione tipo:
@Pre("@value>=0"))
Nei prossimi esperimenti mi ripropongo di approfondire questo punto, selezionando un framework per il design by contract.
Essendo le istanze immutabili, allora ridefinisco anche la equals.
In pratica l'effetto di ridefinire la equals è che due istanze che confrontate restituiscono true vengono considerate come se fosse lo stesso oggetto da varie api di java, come quelle che gestiscono Set e mappe.
Cioè se ridefinisco la equals allora, aggiungendo ad un set vuoto due oggetti istanziati entrambi allo stesso modo (new Natural(1)), la numerosità del set sarà uno, non due.
Se l'oggetto fosse mutabile, ovvero potesse cambiare stato dopo essere istanziato, allora la ridefinizione della equals non va fatta, in quanto possono succedere stranezze, per esempio: un oggetto può venir aggiunto ad un insieme, cambiare stato e misteriosamente sparire virtualmente dall'insieme stesso.
Tra tutte le cose misteriose che con il codice possono succedere, questa è talmente bizzarra che si desidera evitarlo, e dunque la ridefinizione della equals per i soli immutable va accettata come regola. Fare diversamente è un tabù.
Quindi per le classi immutabili va ridefinito il metodo equals (e hashcode), mentre per le classi mutabili no.
Tornando alla classe Natural, ora pongo una questione.
Come deve essere una implementazione conforme al principio Open closed?
Più in dettaglio diciamo che il dominio verrà esteso, e vogliamo allo stesso modo che questo determini il dover "aggiungere del nuovo codice", in conformità a questa estension, ma non "modificare codice esistente".
L'estensione è che bisogna descrivere anche i numeri negativi.
Ribadendo che non posso fare modifiche (per quanto semplici possano essere) ma solo estensioni, allora posso per esempio fare una sottoclasse, il cui costruttore non solleva più l'eccezione se istanziata con un negativo, cioè come segue:
(Per motivi di sintassi java la classe padre deve avere un costruttore a zero argomenti che serve solo alle sottoclassi, e quindi diciamo che è stato già definito in previsione di estensioni, come protected)
public Relative(int value) {
this.value = value;
}
Ancora una volta, in termini di precondizioni, si tratta dell'equivalente del rilassare la precondizione della classe padre (Natural) da restrittiva @Pre("@value>=0"), a meno restrittiva
eliminando semplicemente il vincolo value>0.
(Questo è coerente, tra l'altro, con le regole del dbc (design by contract), per cui le precondizioni in ereditarietà possono essere meno restritive, e non più restrittive, mentre il viceversa vale per le eventuali post-condizioni).
Un'altra precondizione che viene rilassata è quella relativa alla sottrazione, che per i naturali è valida se il sottraendo è minore o uguale al diminuendo, mentre tra i relativi non c'è questo vincolo.
A questo punto si pone il problema che abbiamo due domini regolati da due classi, ma che presentano oggetti assimililabili tra loro:
Natural è padre di Relative, e, insiemisticamente parlando, ne è un sottoinsieme.
Le operazioni di somma e sottrazione sui Natural, continuano ad essere valide per i Relative, con esiti che sono considerati uguali, dunque viene rispettato il principio di sostituibilità.
Dovremmo anche aspettarci che la equals possa ammettere con confronto altrettanto coerente tra istanza di Natural e istanze di Relative?
Secondo me sì per due ragioni. Uno è il principio di fare la scelta meno sorprendente. Sarebbe piuttosto sorprendente che l'istanza new Natural(1) e new Relative(1) vengano considerate diverse tra loro, visto che figurativamente parliamo di insiemi uno sottoinsieme dell'altro, dunque condividono alcuni elementi in comune che dovrebbero continuare ad essere gli stessi, non importa quale sia la classe concreta a cui appartengono.
Un altro motivo è reltivo alla definizione di sostituibilità. Devo poter sostituire, (ad una istanza della classe padre una opportuna istanza della classe figlia) e aspettarmi lo stesso risultato, per qualsiasi codice, e io per qualsiasi codice intendo anche la equals ovvero
(new Natural(1)).equals(new Relative(1)) restituisce true perchè lo fa anche
(new Natural(1)).equals(new Natural(1)).
Questo non è possibile farlo usando l'implementazione della equals basata sulla "getClass()" , ma è invece possibile usando quella basata sulla "instanceof".
Tuttavia questa implementazione potenzialmente può portare a risultati inconsistenti, per particolari classi estese (non in questo caso di estensione da Natural a Rational, comunque).
Per evitare questo ulteriore problema invece si può usare l'implementazione proposta nel seguente articolo: implementig equals() to allow slice comparison.
In conclusione: condizione necessaria affinché una classe che definisce oggetti non mutabili rispetti il principio open closed è che adotti la equals che permetta il "confronto a slices".
Una condizione secondaria, legata a questioni sintattiche di java, è che questa definisca un costruttore vuoto, a zero argomenti, di visibilità protected o superiore.
Note. Non posso dire di averli riletti recentemente, ma gli articoli di riferimento su questo argomento sono i seguenti
principio open closed: www.objectmentor.com/resources/articles/ocp.pdf
equals: http://www.artima.com/weblogs/viewpost.jsp?thread=4744
equals: http://www.artima.com/intv/bloch17.html
principio di sostituibilità di liskov: http://www.objectmentor.com/resources/articles/lsp.pdf
equals basata su confronto a slices (mixed type) : http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals-2.html
