Ciccio92 ha scritto:
public interface ICoordinata {
public double x();
public double y();
}
Questa è ok. Il "public" nei metodi generalmente/tipicamente si omette (sono comunque implicitamente public nelle interfacce) ma è ok metterlo esplicitamente.
Ciccio92 ha scritto:
public abstract class AbstractCoordinata implements ICoordinata{
// [ ... ]
@Override
public double x() {
throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
}
@Override
public double y() {
throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
}
}
Questo NON va bene. Non devi proprio implementarli questi due qui in AbstractCoordinata. Tecnicamente è
lecito definirli concreti come hai fatto qui. Ma se fai così succede una cosa abbastanza grave: per le sottoclassi
manca l'obbligo di implementarli! Ovvero una sottoclasse concreta potrebbe fregarsene, non ridefinirli (poiché sono già concreti in AbstractCoordinata) e quindi poi quando il tuo codice funzionerà con degli oggetti concreti, si schianterà comunque per quei UnsupportedOperationException.
Quello che devi capire è che in AbstractCoordinata NON è un problema se non hai ancora x() e y() concreti. Li avrai con una sottoclasse concreta che li implementa!
In AbstractCoordinata puoi tranquillamente ragionare sui concetti di "distanza" e "somma" senza sapere assolutamente DOVE x()/y() saranno implementati. Concentrati appunto sul concetto.
Quando poi definirai CoordinataXY che sarà concreta, allora lì dovranno essere implementati x() e y() (e che a rigor di logica useranno dei rispettivi campi di istanza).
Quando istanzierai oggetti di tipo CoordinataXY, se su questi invocherai distanza/somma (di AbstractCoordinata), questi metodi useranno i x() e y() che sono implementati appunto nell'oggetto istanziato cioè in CoordinataXY.