Override metodi setter e getter

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

[andbin]

Non vedo come altrimenti accedere a set Colore() di Abbigliamento...

Il setColore di Abbigliamento è PUBBLICO, chiunque lo può invocare!!
E non impone vincoli.