Override metodi setter e getter

[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.

[andbin]

Io avrei utilizzato un codiceColore in Camicia.java, assegnandoli il valore con this.codiceColore = codiceColore

No, ti ripeto che sarebbe una duplicazione del campo. Lo "storage" del valore è in Abbigliamento e i suoi getColore/setColore sono perfettamente usabili dalla sottoclasse (e setColore ri-definibile).

C'è ancora una questione: il costruttore di Camicia riceve il codiceColore e lo passa al costruttore di Abbigliamento. Anche QUI va controllato il valore, perché altrimenti è ovvio che quando crei un oggetto Camicia puoi passare quello che ti pare!

[Gas75]

No, ti ripeto che sarebbe una duplicazione del campo. Lo "storage" del valore è in Abbigliamento e i suoi getColore/setColore sono perfettamente usabili dalla sottoclasse (e setColore ri-definibile).

Ho solo detto come viene da ragionare a me, se prendo un file vuoto e inizio a scrivere del codice...
Procederei in quel modo, che so sbagliato ma le alternative corrette non riesco ad assimilarle.

C'è ancora una questione: il costruttore di Camicia riceve il codiceColore e lo passa al costruttore di Abbigliamento. Anche QUI va controllato il valore, perché altrimenti è ovvio che quando crei un oggetto Camicia puoi passare quello che ti pare!

Non ti seguo.
Come dici tu funziona, processa il codiceColore e, se sbagliato, gli assegna il valore 'X'... Però Camicia ha un suo range di valori possibili per codiceColore, Pantaloni ha un altro range di valori possibili... Che controllo faccio nella superclasse Abbigliamento se un codiceColore è specifico di una sottoclasse? Proprio perché non posso generalizzare questo controllo, ho necessità di farlo nella sottoclasse.