Override metodi setter e getter

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

[andbin]

Che controllo faccio nella superclasse Abbigliamento se un codiceColore è specifico di una sottoclasse?

Se Abbigliamento non ha vincoli sul codiceColore, appunto NON è Abbigliamento che deve fare controlli.

Proprio perché non posso generalizzare questo controllo, ho necessità di farlo nella sottoclasse.

Sì appunto ma nota bene, dove è che passi a Camicia il codiceColore? Al setColore E al costruttore. In entrambi i punti devi applicare un controllo.

[Gas75]

Sì appunto ma nota bene, dove è che passi a Camicia il codiceColore? Al setColore E al costruttore. In entrambi i punti devi applicare un controllo.

Allora... Il costruttore di Camicia l'ho sistemato così...

    public Camicia(int elementoID, String descrizione, char codiceColore, double prezzo, char stile) {
        super(elementoID, descrizione, codiceColore, prezzo);
        switch(codiceColore) {
            case 'B':
            case 'G':
            case 'R':
            case 'U':
                super.setColore(codiceColore);
                break;
            default:
                super.setColore('X');
        }
        this.stile = stile;
    }

E ho tolto l'override di setColore()...
Funziona.
Riepilogando, siccome devo controllare un argomento nella classe specifica, effettuo il controllo nel costruttore ed eventualmente imposto il valore corretto (o un "segnale X se sbagliato, per il momento...) tramite super.setColore() perché è l'unica via d'accesso al private char codiceColore.
Perché non avevo ragionato così e cercato la via dell'override di setColore? Nei costruttori il riferimento super va usato necessariamente come prima istruzione, quindi credevo che, dopo aver passato codiceColore ad Abbigliamento, lo switch dopo fosse "tardivo".
Quindi devo prima passare il codiceColore che ho, giusto o sbagliato che sia, e poi lo convalido sovrascrivendolo. Quindi setColore() della superclasse viene invocato due volte.

Se questo è il ragionamento corretto, cioè passare due volte per setColore() della superclasse (cosa che sinceramente vedo forzata), allora posso fare tutti i controlli degli argomenti nel costruttore e non fare alcun override. Cioè sfrutto l'incapsulamento e non tanto l'ereditarietà...

[andbin]

Perché non avevo ragionato così e cercato la via dell'override di setColore?

L'override di setColore lo DEVI fare perché altrimenti resta il setColore di Abbigliamento, che non ha vincoli e quindi chiunque può settarci quello che gli pare ...

Se questo è il ragionamento corretto, cioè passare due volte per setColore() della superclasse (cosa che sinceramente vedo forzata)

Nel tuo ultimo costruttore di Camicia, il setColore viene invocato 1 volta sola, come flusso di esecuzione intendo, non due.

[Gas75]

L'override di setColore lo DEVI fare perché altrimenti resta il setColore di Abbigliamento, che non ha vincoli e quindi chiunque può settarci quello che gli pare ...

Eppure ho verificato che, con il solo switch nel costruttore Camicia, eventuali valori non corretti di codiceColore vengono tutti convertiti nel segnale X... In pratica setColore() di Abbigliamento lo invoco esclusivamente dopo aver filtrato via i valori non accettabili per quell'oggetto di sottoclasse. Non vedo come altrimenti accedere a set Colore() di Abbigliamento...

Nel tuo ultimo costruttore di Camicia, il setColore viene invocato 1 volta sola, come flusso di esecuzione intendo, non due.

Ok. Ho fatto confusione nello scrivere... Intendevo dire che assegno due volte codiceColore al private di Abbigliamento, è questa sovrascrittura che non mi quadra, ma credo di aver risolto così:

        switch(codiceColore) {
            case 'B':
            case 'G':
            case 'R':
            case 'U':
                break;
            default:
                super.setColore('X');
        }

In sostanza passo ad Abbigliamento codiceColore e lo cambio solo se non è corretto col tipo Camicia.