Override metodi setter e getter

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

[andbin]

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

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

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

[andbin]

I metodi setter (e getter) sono necessariamente pubblici.

Non necessariamente.

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

Continuo a ripeterlo: se in Camicia NON ridefinisci il setColore, resta il setColore di Abbigliamento che NON è vincolato, è pubblico e chiunque può invocarlo per settare quello che gli pare.

[Gas75]

Continuo a ripeterlo: se in Camicia NON ridefinisci il setColore, resta il setColore di Abbigliamento che NON è vincolato, è pubblico e chiunque può invocarlo per settare quello che gli pare.

Ti riferisci a una inizializzazione con riferimento ad Abbigliamento?

Abbigliamento MiaCamicia = new Camicia(/* argomenti del costruttore */);

[andbin]

Ti riferisci a una inizializzazione con riferimento ad Abbigliamento?

Abbigliamento MiaCamicia = new Camicia(/* argomenti del costruttore */);

Lo ripeto ancora ( ). Se in Camicia NON ridefinisci il setColore, Camicia ha il setColore EREDITATO da Abbigliamento.
Quindi che la variabile sia di tipo Abbigliamento o Camicia, il setColore è accessibile (pubblico), è quello di Abbigliamento, che NON è vincolato e quindi chiunque ci setta quello che gli pare.