Esercizio classi astratte

di il
6 risposte

Esercizio classi astratte

Sto facendo alcuni esercizi per diventare un pochino più pratico con le classi astratte e le interfacce visto che non ci ho capito molto e mi si è presentato questo esercizio:

Definire una opportuna gerarchia di classi che rappresenti contribuenti fiscali. La radice di tale gerarchia `e la classe pubblica astratta Contribuente, contenuta nel package contribuente, contenente i campi privati entrate e uscite di tipo double ed (unicamente) i seguenti metodi:

public Contribuente(double entrate, double uscite): crea un oggetto di classe Contribuente ed assegna a ciascun campo dati il valore del parametro omonimo;
abstract public String id(): restituisce l’identificativo del contribuente;
protected double imponibile(): restituisce l’ammontare dell’imponibile, calcolato secondo la formula imponibile = (entrate-uscite)*fds, dove fds rappresenta un fattore di sconto dipendente dal tipo di contribuente (v. sotto);
abstract protected double fattoreDiSconto(): restituisce il fattore di sconto del contribuente (valore compreso tra 0 ed 1);
abstract protected double aliquota(): restituisce l’aliquota del contribuente (valore com- preso tra 0 ed 1, estremi inclusi);
public double daPagare(): restituisce l’ammontare totale delle tasse da pagare, ovvero il prodotto dell’imponibile per l’aliquota.
package contribuente;

public abstract class Contribuente {
    private double entrate;
    private double uscite;
    
    public Contribuente(double entrate, double uscite){
        this.entrate = entrate;
        this.uscite = uscite;
    }
    
    abstract public String id();
    
    protected double imponibile(){
        return (entrate - uscite)*fattoreDiSconto();
    }
    
    abstract protected double fattoreDiSconto();
    
    abstract protected double aliquota();
    
    public double daPagare(){
        return imponibile() * aliquota();
    }
}

Dopo aver realizzato tale classe, definire nel package contribuente.persone la classe pubblica PersonaFisica, implementazione di Contribuente, che rappresenta i contribuenti di tipo “persona fisica”, contenente un campo dati privato codiceFiscale di tipo String ed il costruttore a tre argo- menti public PersonaFisica(double entrate, double uscite, String codiceFiscale,String nome, String cognome) che crea un oggetto di classe PersonaFisica ed assegna a ciascun campo dati il valore del parametro omonimo.

E qui ho i primi dubbi. Dice implementazione, ma non sono solamente le interfacce che si possono implementare? Anche se faccio una classe con extends Contribuente comunque deve rimanere astratta. Quindi a che serve fare delle classi astratte se poi alla fine le derivate sempre astratte possono essere e quindi è impossibile implementarle? Avete qualche risorsa dove posso leggere l'utilità delle classi astratte e interfacce? All'università il professore non ne ha proprio parlato e quindi anche se mi sembra una cosa per mantenere tutto in ordine e strutturato non ne vedo l'utilità. PS potete controllare anche se ho scritto bene la classe precedente?

6 Risposte

  • Re: Esercizio classi astratte

    squizzi ha scritto:


    package contribuente;
    
    public abstract class Contribuente {
         .....
    
    La classe mi pare a prima vista tecnicamente corretta (non ho provato a compilarla ma non vedo errori grossolani.
    Abituati solo a mettere sempre prima il livello di accesso: public abstract .... non abstract public. Questa perlomeno è la convenzione tipica.

    squizzi ha scritto:


    Dice implementazione, ma non sono solamente le interfacce che si possono implementare?
    Se in una sotto-classe fai un "override" con un metodo non astratto, di un metodo che è astratto nella super-classe, allora si dice appunto che "implementi" tale metodo.
    Non è sbagliato, in senso generale (è indicato anche nel Java Language Specification).

    squizzi ha scritto:


    Anche se faccio una classe con extends Contribuente comunque deve rimanere astratta.
    Perché pensi questo? Da quello che si può immaginare dalla richiesta, ci si aspetterebbe che una sotto-classe come PersonaFisica sia "concreta" e quindi non astratta perché puoi (credo sicuramente) implementare in modo concreto i metodi astratti.
  • Re: Esercizio classi astratte

    Ora ho capito, l'errore mi usciva perchè non avevo l'ovveride dei metodi astratti e quindi risultava avere metodi astratti e una classe che ha dei metodi astratti deve essere astratta. Grazie mille della disponibilità solamente che faccio abbastanza confusione con queste cose. Con l'esempio ho capito più o meno come può essere utile avere una classe astratta solamente che ancora non capisco bene l'utilizzo pratico. Hai qualche testo che puoi suggerirmi? ho abbandonato l'università quindi dovrei fare da autodidatta e sto ripassando java con il manuale di de sio e in più studiando algorithms part 4...altre cose oltre la pratica?
  • Re: Esercizio classi astratte

    squizzi ha scritto:


    solamente che ancora non capisco bene l'utilizzo pratico.
    Una classe astratta è utile quando non ha senso poter istanziare una certa classe, perché tipicamente rappresenta un concetto "astratto".
    Se ne possono fare svariati di esempi anche abbastanza realistici. Uno semplice da capire: una gerarchia di classi che rappresentano forme "solide".
    Quindi ad esempio una classe base Solido e poi sotto-classi es. Cubo, Sfera, Cilindro, ecc...

    Domandati: ha senso poter istanziare Solido? Solido .... di che? Cosa sarebbe? Direi nulla di sensato e concreto. In questa gerarchia gli oggetti potrebbero avere un calcolaSuperficie() e calcolaVolume() (restituendo il risultato come es. double). In una classe come Solido, che rappresenta un concetto molto generale e non ben definibile, come potrebbero essere implementati?

    Appunto ... non avrebbe senso. E pertanto Solido è sicuramente un ottimo candidato per essere marcato abstract.
  • Re: Esercizio classi astratte

    Come ad esempio una classe veicolo...quindi alla fine si potrebbe partire da una classe che si vuole realizzare e con il metodo is a... arrivare alla classe astratta. Più o meno va bene come ragionamento? mentre le interfacce?
  • Re: Esercizio classi astratte

    squizzi ha scritto:


    come ad esempio una classe veicolo...
    Sì più o meno, ma bisogna vedere cosa si vuole far fare ad una classe Veicolo. Cioè se deve essere solo una normale classe "bean" che contiene proprietà (e senza sotto-classi) o se si vuole realizzare una gerarchia di classi perché ciascuna ha un "comportamento" più specifico.

    Nell'esempio che ho fatto prima, delle forme solide, è molto più chiaro ed intuitivo. La determinazione di superficie/volume richiede dei calcoli che sono anche ben differenti tra le varie forme, quindi ci vuole codice (un "comportamento") specifico e pertanto una gerarchia di classi che sfrutta l'ereditarietà e il principio di override dei metodi è la cosa più naturale.

    squizzi ha scritto:


    quindi alla fine si potrebbe partire da una classe che si vuole realizzare e con il metodo is a... arrivare alla classe astratta. Più o meno va bene come ragionamento?
    In generale sì ma cerca sempre di valutare caso per caso.

    squizzi ha scritto:


    mentre le interfacce?
    Innanzitutto una interfaccia la devi vedere concettualmente come se fosse una classe astratta al 100%. Ovvero tutto astratto, definisce solo cosa un oggetto deve fare ma non come lo deve fare..

    Poi siccome le interfacce le puoi implementare in qualunque classe a qualunque livello di una gerarchia e per via del fatto che sono sempre completamente astratte, esse rappresentano un punto di astrazione più elevato rispetto a classi normali/astratte.

    Le interfacce vengono solitamente utilizzate per definire un "contratto" (tra più entità) e tipicamente per descrivere la capacità di saper fare una certa cosa. Nel framework standard ci sono interfacce come Runnable (capacità di eseguire qualcosa), Iterable (capacità di iterare qualcosa), Comparable (capacità di comparare qualcosa) e così via.
  • Re: Esercizio classi astratte

    Grazie mille della disponibilità hai fatto chiarezza su molti dubbi che avevo. Ora no resta che fare tanta pratica e tutto verrà naturale
Devi accedere o registrarti per scrivere nel forum
6 risposte