Svolgere un esercizio per capire le interfacce.

di
FabioJ
il
30 risposte
F
FabioJ
Utente Attivo
Iscritto da
mag, 2017
Messaggi:
119

Svolgere un esercizio per capire le interfacce.

Mi aiutate a risolvere questo esercizio.
Voglio capire bene la funzione della interfacce e delle classi astratte.

Una software house sta sviluppando un’applicazione per la simulazione di sistemi urbani con diversi veicoli , sia automobili che motociclette .
Tra le classi significative segnaliamo:


public class Automobile {
private static int PERSONE_TRASPORTABILI =5;
private int anno; // di immatricolazione
public Automobile(int a) {
this.anno = a;
}
public int getAnno() {
return this.anno;
}
Public int getTrasportabili() {
Return PERSONE_TRASPORTABILI;
}
}
public class Motocicletta {
private static int
PERSONE_TRASPORTABILI = 2;
private int anno; // di immatricolazione
public Motocicletta(int a ) {
this.anno = a;
}
Public int getAnno(){
return this.anno;
}
Public int getTrasportabili() {
Return PERSONE_TRASPORTABILI
}
}


Che devono essere riscritte di modo da implementare un’interfaccia comune Veicolo .
Scrivere il codice dell’interfaccia comune Veicolo e riscrivere ( ampliando le funzionalita’ ) le classi Automobili e Motocicletta di modo che sia possibile creare oggetti che modellino veicoli(automobili e motociclette) di anno di immatricolazione e targa specificati all’atto della costruzione .



Svolgimento :

prima di tutto devo creare una classe astratta che chiamo Veicolo .

interface Veicolo
{
public String getVeicolo();
}

Provo a riscrivere le classi

public class Automobile implements Veicolo {
private static int PERSONE_TRASPORTABILI =5;
private int anno; // di immatricolazione
public Automobile(int a) {
this.anno = a;
}
public String getVeicolo(); {

}

public class Motocicletta implements Veicolo {
private static int
PERSONE_TRASPORTABILI = 2;
private int anno; // di immatricolazione
public Motocicletta(int a ) {
this.anno = a;
}
Public int getAnno(){
return this.anno;
}
Public int getTrasportabili() {
Return PERSONE_TRASPORTABILI
}
public String getVeicolo(); {

}

}


Secondo voi e' giusto fin qui ? E' corretto modificare il codice in questo modo ?
E' giusto il metodo String getVeicolo() nelle classi Automobile e Motocicletta che richiamano l'interfaccia?

30 Risposte

  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Svolgere un esercizio per capire le interfacce.

    FabioJ ha scritto:

    Secondo voi e' giusto fin qui ? E' corretto modificare il codice in questo modo ?
    Per come è letteralmente postato qui, no, non è corretto.

    FabioJ ha scritto:

    E' giusto il metodo String getVeicolo() nelle classi Automobile e Motocicletta che richiamano l'interfaccia?
    Le due classi devono implementare il metodo getVeicolo(). Ovvero devi mettere un getVeicolo con quella esatta signature e con un "corpo" tra { } che restituisce una stringa.

    Quale stringa? Tecnicamente in ciascuna classe devi tenere un campo (variabile) di istanza di tipo String per quella stringa. Il getVeicolo semplicemente restituisce quel campo.
    Chi lo setta questo campo? Dipende (dai requisiti) .... potrebbe essere un metodo setter specifico nella classe e/o il costruttore che lo riceve come argomento.
  • F
    FabioJ
    Utente Attivo
    Iscritto da
    mag, 2017
    Messaggi:
    119

    Re: Svolgere un esercizio per capire le interfacce.

    Vorrei Ricominciare da capo a risolvere questo esercizio procedendo passo passo.

    Il testo dice :

    Le classi devono essere riscritte di modo da implementare un’interfaccia comune Veicolo .
    Scrivere il codice dell’interfaccia comune Veicolo e riscrivere ( ampliando le funzionalita’ ) le classi Automobili e Motocicletta di modo che sia possibile creare oggetti che modellino veicoli(automobili e motociclette) di anno di immatricolazione e targa specificati all’atto della costruzione .


    primo passo : Le classi devono essere riscritte di modo da implementare un’interfaccia comune Veicolo

    risposta :

    Public interface Veicolo
    {
    void ModellaVeicolo();
    }

    Puo' andar bene questo frammento di codice come prima risposta all'esercizio ?
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Svolgere un esercizio per capire le interfacce.

    FabioJ ha scritto:

    Public interface Veicolo
    {
    void ModellaVeicolo();
    }

    Puo' andar bene questo frammento di codice come prima risposta all'esercizio ?
    E cosa dovrebbe fare concettualmente ModellaVeicolo ??

    A questo livello della interfaccia devi elencare tutti i metodi che TUTTE le implementazioni dovranno avere e definire concretamente. E quindi devi ragionare su cosa ha senso mettere a questo livello abbastanza "astratto" (nel senso di livello teorico dei veicoli).
  • F
    FabioJ
    Utente Attivo
    Iscritto da
    mag, 2017
    Messaggi:
    119

    Re: Svolgere un esercizio per capire le interfacce.

    Cerco di ragionare e lasciare perdere per il momento l'aspetto tecnico del codice .

    Le classi sono Automobili e Motociclette .
    Se non ho capito male devo implementare dei metodi che modellano gli oggetti delle classi Automobili e Motociclette utilizzando un'interfaccia.
    Per modellare queste due Classi devo aggiungere gli attributi anno di immatricolazione e targa a ciascuna classe.

    Questo ragionamento puo' andar bene ?
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Svolgere un esercizio per capire le interfacce.

    FabioJ ha scritto:

    Cerco di ragionare e lasciare perdere per il momento l'aspetto tecnico del codice .

    Le classi sono Automobili e Motociclette .
    Se non ho capito male devo implementare dei metodi che modellano gli oggetti delle classi Automobili e Motociclette utilizzando un'interfaccia.
    Allora partiamo dall'inizio. Una interfaccia Veicolo rappresenta a livello "astratto" un qualche veicolo, mezzo di trasporto.
    Cosa ha senso mettere nella interfaccia? Quali sono le cose che ragionevolmente ti aspetti che TUTTI i veicoli (perlomeno quelli reali che vorrai considerare) hanno sicuramente in comune? Di veicoli ne esistono tanti e chiaramente più vai ad ampliare la visione sui veicoli in generale e meno cose troverai in comune.

    Ci sono due cose che mi vengono in mente che tutti (ma proprio tutti!) i veicoli hanno in comune: la marca e il modello.

    Quindi potrei mettere es.

    String getMarca();
    String getModello();

    Mettiamo anche i metodi "setter"? Qui la scelta è importante. Se nella interfaccia metti anche i setter, vai a forzare tutte le implementazioni a dover implementare i setter e, ragionevolmente, ad essere "mutabili".
    Poi una implementazione potrebbe avere il setter vuoto o che lancia es. UnsupportedOperationException ma non è una bella cosa in generale.
  • F
    FabioJ
    Utente Attivo
    Iscritto da
    mag, 2017
    Messaggi:
    119

    Re: Svolgere un esercizio per capire le interfacce.

    Lasciando stare i setter che ho capito che si devono mettere pero' non ho capito la loro funzione . Li inserisco insieme ai getter in automatico dopo aver instanziato .
    Comunque per il momento un punto fermo credo di poterlo mettere nello svolgimento di questo esercizio e cioe' :


    interface Veicolo
    {
    String getMarca();
    String getModello();

    }
  • F
    FabioJ
    Utente Attivo
    Iscritto da
    mag, 2017
    Messaggi:
    119

    Re: Svolgere un esercizio per capire le interfacce.

    Per il momento devo fermarmi qui ..sperando domani tu possa aiutarmi ancora nel ragionamento e nello svolgimento di questo esercizio.

    Grazie ..
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Svolgere un esercizio per capire le interfacce.

    FabioJ ha scritto:

    Lasciando stare i setter che ho capito che si devono mettere pero' non ho capito la loro funzione .
    Attenzione. Una implementazione concreta es. Automobile può avere un setModello(String modello) ma la interfaccia potrebbe NON dichiararlo questo setter!
    Se mettere i setter già a livello di interfaccia è un aspetto di "design" importante che va valutato caso per caso. Se metti un setter già nella interfaccia, imponi a TUTTE le implementazioni di averlo e, ragionevolmente parlando, a definire quindi oggetti "mutabili".

    FabioJ ha scritto:

    interface Veicolo
    {
    String getMarca();
    String getModello();

    }
    Corretto. (metti la interface come public, se non ci sono questioni particolari)
  • M
    migliorabile
    Super Famoso
    Iscritto da
    apr, 2013
    Messaggi:
    5846

    Re: Svolgere un esercizio per capire le interfacce.

    Un buon modo per capre l'uso delle interfacce e le classi astratte potrebbe essere il seguente:
    Supponi di essere in un team composto da:

    1) il team leader
    2) il gruppo di persone che si occupano di sviluppare il codice per le Automobili
    3) il gruppo di persone che si occupano di sviluppare il codice per le Motociclette
    4) i due gruppi si stanno sulle scatole tra di loro e quindi non si parlano (un classico tra automobilisti e bikers )

    Ora, al Team Leader, NON INTERESSA MINIMAMENTE sapere se gli oggetti sono Automobili o Biciclette, sono TUTTI oggetti che hanno una marca, un modello, una targa, ecc.
    QUINDI, il team leader, quando progetta la sua parte di codice, per quanto riguarda Automobili e Biciclette, RAGIONA in termini di interfaccia: entrambi gli oggetti DEVONO fornire un certo numero di servizi, ma non gli interessa minimamente sapere come sono implementati

    Ora consideriamo uno dei due gruppi, visto che per il ragionamento sarebbe esattamente lo stesso per l'altro.
    Supponiamo di prendere in cosiderazione il gruppo che sviluppa il codice per le Motociclette.

    Ora, affiche' l'oggetto Motocicletta possa essere usato nel codice del team leader, DEVE implementare l'interfaccia che e' stata identificata.
    E con questo abbiamo concluso la parte relativa all'interfaccia

    Ed ora vediamo la parte di COME implementare l'oggetto Motocicletta.
    Supponiamo, per N-mila motivi, che sia necessario implementare una classe per OGNI marca di Motocicletta. Quindi, si avranno le classi

    - Ducati
    - Suzuki
    - Honda
    - ...

    E' ovvio che l'implementazione di queste classi avranno delle parti in comuni, che metterai nella CLASSE BASE Motocicletta.

    E' anche necessario, pero', assicurarsi che qualche bischero di programmatore alle prime armi (ogni rifrimento a cose e persone realmente esistenti NON E' puramente casuale ), non faccia la castronata di istanziare DIRETTAMENTE la classe Motocicletta.
    Per fare questo, dichiari che la classe Motocicletta e' ASTRATTA.

    Tra l'altro, in una classe ASTRATTA hai anche la possibilita' di dichiarare un metodo SENZA necessariamente assegnare un'implementazione.
    Questo fa si che chi deriva dalla classe Motocicletta per implementare, che ne so, la classe "Icon" (si, e' una marca di motociclette e la "Icon Sheen" costa la belezza di 120.000 euro!!!) DEVE assicurarsi di implementare anche quel particolare metodo.
    E con questo sai tutto sulle classi astratte.
  • M
    migliorabile
    Super Famoso
    Iscritto da
    apr, 2013
    Messaggi:
    5846

    Re: Svolgere un esercizio per capire le interfacce.

    I getter ed i setter sono un'altra questione.

    Un getter serve per LEGGERE un'informazione da un oggetto
    Un setter serve per CAMBIARE un'informazione da un oggetto.

    Nota che o scritto CAMBIARE, e NON IMPOSTARE: qui la questione e' subdola/delicata/filosofica.

    Prova a pensarla cosi': quando tu istanzi un oggetto di classe "Honda", devi specificare il modello, diciamo 'VFR1200F'
    Ma una volta specificato il "modello", quell'oggetto rappresenta una particolare moto di marca Honda e modello 'VFR1200F'.

    Ora, ha senso immaginare che quell'oggetto un domani CAMBI modello? Diventi una 'GSX-R1000R ABS' (che, guarda caso, e' un modello della Suzuki!!! Ma visti che si puo' cambiare, uno potrebbe anche sbagliare ) Direi di no!
    Facciamo un passetto ulteriore: quell'oggetto rappresenta una GENERICA 'Honda VFR1200F' OPPURE una 'Honda VFR1200F con targa GO123456'?
    Diciamo che rappresenta una 'Honda VFR1200F con targa GO123456'.

    Ha senso poter LEGGERE marca, modello e traga da questo oggetto? Ovviamente anche perche' molto probabilmente sono informazioni richeiste dall'interfaccia di cui sopra.

    Ha SENSO poter cambiare questi valori? Ovviamente No. Vabbe' sulla targa potremmo filosofare ...

    Quindi implementerai i getter MA NON i setter.

    Invece, tra le informazioni utili, una potrebbe essere il numero di chilometri percorso.
    Questo e' un valore che cambia nel tempo, e quindi va aggiornato con regolarita: ti SERVE il getter E il setter.

    Allora, se non ci sono i setter, COME IMPOSTO i valori?

    Semplice, NEL COSTRUTTORE!!!!!


    In pratica, la parte filosofica e' la seguente:

    il tuo oggetto e'
    1) un CONTENITORE che contiene generiche informazioni, e quindi ti servono i setter per ogni possibile campo), OPPURE
    2) UN ESEMPLARE UNICO, e che, quindi, una volta istanziato, puoi solo chiedere chi e'?

    Se vuoi (e' un po' macabro ): e' la differenza che c'e' tra la pelle, intesa come qualcosa che ti copre, e gli abiti che indossi, ma che potrebbero essere indossati da chiunque altro.


    Nota: vado un po' controcorrente rispetto ad @andbin
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Svolgere un esercizio per capire le interfacce.

    migliorabile ha scritto:

    Nota: vado un po' controcorrente rispetto ad @andbin
    No no, hai detto tutto giusto ... è quanto avrei potuto dire pure io.

    Io di particolare gli ho solo detto che se dichiarare o no un "setter" già a livello di interfaccia è un aspetto di "design" da valutare sempre bene, perché la interfaccia è un "contratto" poi da rispettare in tutte le implementazioni.

    Non è un caso che nel framework standard di JavaSE ci sono interfacce come la TreeNode (per il JTree di Swing) che espone metodi SOLO per estrarre informazioni senza poter modificare nulla e poi hanno fatto una sotto-interfaccia MutableTreeNode che espone metodi per modificare il nodo.
    Insomma, da qualche parte si potrebbe voler "vedere" un nodo solo per ottenere informazioni mentre magari da un'altra parte si potrebbe voler "vedere" a livello astratto un nodo ma che sia MUTABILE.
  • F
    FabioJ
    Utente Attivo
    Iscritto da
    mag, 2017
    Messaggi:
    119

    Re: Svolgere un esercizio per capire le interfacce.

    Grazie Migliorabile .

    Sei il migliore senza togliere niente a andbin .

    A parte gli scherzi e i convenevoli volevo dirti che con la tua spiegazione ho le idee meno confuse ed ho capito a cosa serve il setter e abbastanza le interfacce anche se per ora solo teoricamente.

    Per esempio se voglio cambiare un attributo di un oggetto uso il setter .

    L'oggetto Moto della classe veicoli che ho impostato in origine con l'attributo colore giallo posso cambiarlo quando voglio in colore rosso .

    Comunque per risolvere questo esercizio devo scioglier ancora altri nodi altrimenti la data dell'esame si allontana sempre piu'.

    Che poi mi accorgo che leggendo bene e piu' volte il testo dell'esercizio le cose non sono cosi' difficili.

    Tutto si semplifica quando le cose si capiscono.
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Svolgere un esercizio per capire le interfacce.

    FabioJ ha scritto:

    ho capito a cosa serve il setter

    Per esempio se voglio cambiare un attributo di un oggetto uso il setter .
    Aggiungo una cosa importante, di "background" generale. Hai già visto che ci possono essere metodi "getter" e "setter" fatti come per es.:

    String getModello()
    void setModello(String modello)

    Perché non li hanno chiamati es. retrieveModello/assignModello o che altro? Per via di alcune "convenzioni" dettate da una specifica chiamata "JavaBeans API specification" definita nel lontano 1996 che descrive un modello di componenti che espongono proprietà, eventi e altro. Questi componenti sono detti "bean" Java.
    Se un oggetto ha i metodi come quelli indicati, allora viene desunta una proprietà "modello" (m minuscola) di tipo String.

    Questa specifica, almeno a livello basilare riguardo le proprietà, viene usata e rispettata ormai da tantissime librerie e framework. In pratica tutti i framework che fanno mapping tra classi, mapping tra classi e formati di file (es. JSON, XML), nelle pagine JSP con i custom-tag e sicuramente altro che ora non mi viene in mente.

    Quindi se vedi metodi come quelli sopra, basta che sai che il "getter" (es. getModello) ti permette di estrarre una informazione dall'oggetto mentre il "setter" (es. setModello) ti permette di settare una informazione nell'oggetto.
    Non necessariamente ci sono sempre tutti e due. Può esserci solo il getter, nel qual caso quella informazione è (se non ci sono altri inghippi) a "sola lettura". E' raro (ma non impossibile) che ci sia solo il setter.

    FabioJ ha scritto:

    Sei il migliore senza togliere niente a andbin .
    Siamo entrambi competenti e in gamba, lui (migliorabile) ha più nozioni di me in ambito teorico. Io ad esempio la "teoria dei grafi" (per dirne una ..) non l'ho mai affrontata particolarmente. Ma tieni presente che io non ho fatto l'università.
  • F
    FabioJ
    Utente Attivo
    Iscritto da
    mag, 2017
    Messaggi:
    119

    Re: Svolgere un esercizio per capire le interfacce.

    Immaginatevi un bambino di cinque anni che deve imparare a portare la bicicletta .
    Ben diverso ad un bambino di cinque anni insegnargli a guidare un Kart .
    Questa e' un po' la mia condizione .
    Le spiegazioni di andbin sono per me ancora un tantino troppo complicate .

    Comunque molto bravo e disponibile.
Devi accedere o registrarti per scrivere nel forum
30 risposte