Override metodi setter e getter

[Gas75]

Salve, vorrei capire meglio il discorso sull'override dei metodi tra classi in gerarchia.
Faccio l'esempio che mi sta dando problemi così arrivo subito al punto senza troppi giri di parole.
La superclasse è questa:

public class Abbigliamento {	// Campi
	private int elementoID = 0; // Default ID
	private String descrizione = "-descrizione richiesta-"; // default
	private char codiceColore = 'U'; //'U' = Unset
	private double prezzo = 0.0; // Default
	// Costruttore
	public Abbigliamento(int elementoID, String descrizione, char codiceColore, double prezzo) {
		this.elementoID = elementoID;
		this.descrizione = descrizione;
		this.codiceColore = codiceColore;
		this.prezzo = prezzo;
	}
	public void display() {
		System.out.println("ID elemento: " + getElementoID());
		System.out.println("Descrizione: " + getDescrizione());
		System.out.println("Prezzo: " + getPrezzo());
		System.out.println("Codice colore: " + getColore());
	} // fine del metodo display
	public String getDescrizione() {
		return descrizione;
	}
	public double getPrezzo() {
		return prezzo;
	}
	public int getElementoID() {
		return elementoID;
	}
	public char getColore() {
		return codiceColore;
	}
	public void setElementoID(int elementoID) {
		this.elementoID = elementoID;
	}
	public void setDescrizione(String descrizione) {
		this.descrizione = descrizione;
	}
	public void setColore(char codiceColore) {
		this.codiceColore = codiceColore;
	}
	public void setPrezzo(double prezzo) {
		this.prezzo = prezzo;
	}
}

Poi ho una sottoclasse Camicia dove vorrei sovrascrivere serColore() e getColore() perché magari voglio implementare uno switch di controllo del char inserito che è personalizzato per quel tipo:

public class Camicia extends Abbigliamento {	private char stile = 'U';
	private char codiceColore = 'A';
	public Camicia(int elementoID, String descrizione, char codiceColore, double prezzo, char stile) {
		super(elementoID, descrizione, codiceColore, prezzo);
		this.stile = stile;
	}
	public char getStile() {
		return stile;
	}
	public void setStile(char stile) {
		this.stile = stile;
	}
	//Questo metodo sovrascrive display della superclasse Abbigliamento
	public void display() {
		System.out.println("Camicia ID: " + getElementoID());
		System.out.println("Camicia descrizione: " + getDescrizione());
		System.out.println("Camicia prezzo: " + getPrezzo());
		System.out.println("Codice colore: " + getColore());
		System.out.println("Stile: " + getStile());
	} // fine del metodo display
	// Questo metodo sovrascrive il metodo della superclasse
	public char getColore() {
		return codiceColore;
	}
	public void setColore(char codiceColore) {
		switch(codiceColore) {
			case 'B':
			case 'G':
			case 'R':
			case 'U':
				this.codiceColore = codiceColore;
				break;
			default:
				System.out.println("Codice colore errato!");
		}
	}
}

Infine ho la semplice classe test:

public class LaCamicia {	public static void main(String args[]) {
		Camicia LaCamicia = new Camicia(123, "Camicia elegante", 'R', 33.99, 'S');
		LaCamicia.display();
	}
}

Succede che viene invocato il display() (overridden) di Camicia, ma mi stampa il codiceColore iniziale di Camicia, 'A' quindi non riesco a passare il parametro 'R' mentre gli altri valori arrivano a destinazione.
Cosa non va? Sospetto l'invocazione al costruttore di Abbigliamento con super(), ma se non faccio così non posso passare gli altri valori...

[andbin]

Cosa non va?

Innanzitutto una questione rilevante. C'è un campo codiceColore sia in Abbigliamento che in Camicia. Questo vuol dire che quando crei un oggetto Camicia questa ha DUE campi codiceColore distinti.

Volevi fare così (per qualche motivo che ignoro....) ... o è una tua svista??

[Gas75]

Inizialmente il campo codiceColore non c'era proprio in Camicia. L'ho introdotto per poter compilare l'override del setColore, che prima era in Abbigliamento ma l'ho voluto differenziare in base al tipo di indumento.

Vige quindi la regola che solo i metodi si sovrascrivono ma i campi no?

[andbin]

Vige quindi la regola che solo i metodi si sovrascrivono ma i campi no?

L' "override" NON esiste per i campi. Al massimo si parla di "hiding", cioè il fatto che una sottoclasse ha un campo il cui nome semplicemente nasconde quello di un campo nella superclasse con lo stesso nome .... e a patto che quello sia "ereditato", cioè accessibile. Se il campo nella superclasse è private, non è ereditato e quindi non c'è neanche hiding.

public class Prova {
    public static void main(String[] args) {
        new B().prova();
    }
}

class A {
    protected int val = 123;   // visibile dalla sottoclasse
}

class B extends A {
    protected int val = 456;   // "nasconde" il val di A

    public void prova() {
        System.out.println(val);         // 456
        System.out.println(super.val);   // 123
    }
}

[Gas75]

Scusami, lo so che l'override è solo dei metodi: per sovrascrivere intendevo dire se il campo della superclasse viene occultato da un omonimo della sottoclasse, e chiaramente per accedervi devo usare super.
Nel mio caso ho necessità di sovrascrivere un metodo, ma non riesco a fare arrivare 'R' nel setColore della sottoclasse.

[andbin]

Scusami, lo so che l'override è solo dei metodi: per sovrascrivere intendevo dire se il campo della superclasse viene occultato da un omonimo della sottoclasse, e chiaramente per accedervi devo usare super.
Nel mio caso ho necessità di sovrascrivere un metodo, ma non riesco a fare arrivare 'R' nel setColore della sottoclasse.

- Togli il campo codiceColore da Camicia (non ha senso, se non mi dai una spiegazione plausibile)
- Togli il getColore() da Camicia (non potresti più usare il campo, che è private nella superclasse .... e comunque non farebbe nulla di più del getColore() di Abbigliamento)
- Nel setColore di Camicia usa super.setColore( .... ); per invocare il setColore della superclasse che È in grado di accedere al suo campo)


P.S.1) un setter che stampa un messaggio di errore non è granché buono ... sarebbe meglio una eccezione.

P.S.2) c'è comunque la questione concettuale che la tua Camicia fornisce una "restrizione" per il setColore. Questo vuol dire che oggetti Camicia NON sono perfettamente sostituibili ovunque sia richiesto un Abbigliamento.

[Gas75]

- Togli il campo codiceColore da Camicia (non ha senso, se non mi dai una spiegazione plausibile)
- Togli il getColore() da Camicia (non potresti più usare il campo, che è private nella superclasse .... e comunque non farebbe nulla di più del getColore() di Abbigliamento)
- Nel setColore di Camicia usa super.setColore( .... ); per invocare il setColore della superclasse che È in grado di accedere al suo campo)

Così la 'R' finalmente viene stampata , ma mi sono giocato il controllo switch, e mi stampa qualunque char. Non posso mettere lo switch nel setColore() della superclasse perché i colori sono potenzialmente differenti in base al tipo di abbigliamento.

P.S.1) un setter che stampa un messaggio di errore non è granché buono ... sarebbe meglio una eccezione.

P.S.2) c'è comunque la questione concettuale che la tua Camicia fornisce una "restrizione" per il setColore. Questo vuol dire che oggetti Camicia NON sono perfettamente sostituibili ovunque sia richiesto un Abbigliamento.

1) ok il println() non è infatti necessario, ma tanto lo switch è rimasto /* commentato */ .
2) non so se ho capito bene... Non amo creare oggetti Camicia riferiti ad Abbigliamento e poi fare casting per usare un metodo di Camicia.

[andbin]

ma mi sono giocato il controllo switch, e mi stampa qualunque char. Non posso mettere lo switch nel setColore() della superclasse

Guarda che nel setColore di Camicia puoi fare tutti gli switch e test che vuoi sul parametro! Come dicevo prima (ma deduco che non sono stato troppo chiaro ...), l'unica cosa particolare è che quando hai verificato che il valore è appropriato ed accettabile, devi semplicemente invocare tu super.setColore(codiceColore); perché solo il setColore di Abbigliamento ha accesso al campo, essendo private.

2) non so se ho capito bene... Non amo creare oggetti Camicia riferiti ad Abbigliamento e poi fare casting per usare un metodo di Camicia.

Non c'entrano i cast. Si intende il fatto che se hai una variabile di tipo Abbigliamento e vuoi invocare polimorficamente setColore (senza cioè "sapere" a priori che oggetto realmente è), per un certo valore ti funziona oppure no a seconda della implementazione del setColore se impone restrizioni oppure no.

Principio di sostituzione di Liskov

[Gas75]

Guarda che nel setColore di Camicia puoi fare tutti gli switch e test che vuoi sul parametro! Come dicevo prima (ma deduco che non sono stato troppo chiaro ...), l'unica cosa particolare è che quando hai verificato che il valore è appropriato ed accettabile, devi semplicemente invocare tu super.setColore(codiceColore); perché solo il setColore di Abbigliamento ha accesso al campo, essendo private.

Non sei tu a essere poco chiaro, sono io che non "arrivo" a certi concetti.
Sul fatto che l'unica porta d'accesso a un private è il setColore() della classe stessa, non ho dubbi, né li avevo quando ho aperto questa discussione. Il problema (il MIO problema) è sorto nel cercare di fare override di setColore() per controllare nella sottoclasse la correttezza del valore di un campo che la sottoclasse può modificare tramite l'opportuno metodo setter.
Ora io credo di aver fatto come suggerisci, ma display() stampa qualunque codiceColore, ignorando lo switch di controllo.

    public void setColore(char codiceColore) {
        switch(codiceColore) {
            case 'B':
            case 'G':
            case 'R':
            case 'U':
                super.setColore(codiceColore);
                break;
            default:
                System.out.println("Codice colore errato!");
        }
    }

Io avrei utilizzato un codiceColore in Camicia.java, assegnandoli il valore con this.codiceColore = codiceColore, e poi passato quel valore a super.setColore()... Ma quel campo l'abbiamo tolto, e comunque non funzionerebbe nemmeno così, anche se spontaneamente mi viene da ragionare così per risolvere la questione.

[Gas75]

I metodi setter (e getter) sono necessariamente pubblici.
L'unico accesso dall'esterno al programma da parte di chiunque è attraverso l'istanza di un oggetto Camicia (o di un'altra sottoclasse di Abbigliamento).
A tale proposito ho impostato un controllo a monte dei possibili valori che passo a un metodo setter. Lo stesso potrei fare per esempio per controllare che un prezzo immesso sia positivo, ma quello ha più senso nel costruttore della superclasse essendo un controllo coerente per tutti gli articoli (sottoclassi).
Magari mi è sfuggito qualcosa ma a me non pare che, nell'ambito di un'istanza di Camicia, sia possibile stampare un codiceColore non contemplato nello switch.