Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1

    Primi approcci: le interfacce

    Ciao a tutti,
    mi sto avvicinando al mondo di Java, e devo dire che non è proprio cosi semplice come credevo.

    Sto avendo numerose difficolta... in questo post mi limito a chiedere chiarimento su una in particolare: le interfacce! PERCHE usarle?

    cioé: io dichiaro un'interfaccia, in cui dichiaro semplicemente i metodi che dovranno poi essere implementati dalla classe che usa l'interfaccia. Ma allora non faccio prima a non dichiarare per niente l'interfaccia? tanto poi quei metodi li devo COMUNQUE implementare nella classe...

    Ovviamente c'è qualche cosa che non ho capito... :master: :master: :master:

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284

    Re: Primi approcci: le interfacce

    Originariamente inviato da gasparirob
    Sto avendo numerose difficolta... in questo post mi limito a chiedere chiarimento su una in particolare: le interfacce! PERCHE usarle?

    cioé: io dichiaro un'interfaccia, in cui dichiaro semplicemente i metodi che dovranno poi essere implementati dalla classe che usa l'interfaccia. Ma allora non faccio prima a non dichiarare per niente l'interfaccia? tanto poi quei metodi li devo COMUNQUE implementare nella classe...
    Le interfacce servono a definire un "contratto". Se tu dichiari di implementare una interfaccia in una tua classe "concreta" (non astratta), sei obbligato a fornire una implementazione per tutti i metodi della interfaccia.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3
    Si, ma perche ?

    perche usare le interfacce? perche definire un "contratto"?
    potresti fare un esempio chiarificatore?

  4. #4
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Originariamente inviato da gasparirob
    Si, ma perche ?
    Java ha solo la "ereditarietà singola", ovvero una classe può derivare da una sola e unica altra classe. Questo è ovviamente molto limitante. Ed è per questo che esistono le interfacce, per dare la possibilità a più classi diverse e magari totalmente scorrelate tra di loro di essere "viste" come un tipo specifico che definisce un "comportamento" (funzionalità) comune che ogni classe dovrà implementare in modo particolare.


    Esempio (è il primo che mi viene in mente ... magari non è il massimo ma può dare bene l'idea):

    codice:
    interface Vendibile {
        double getPrezzo();
    }
    
    
    class Libro implements Vendibile {
        private double prezzo;
    
        // .....
    
        public double getPrezzo () {
            return prezzo;
        }
    }
    
    class Panino implements Vendibile {
        private double prezzo;
    
        // .....
    
        public double getPrezzo () {
            return prezzo;
        }
    }
    Vendibile definisce un qualcosa che è vendibile e che ha un prezzo. Se da qualche parte c'è ad esempio un metodo:

    public boolean controllaPrezzo (Vendibile v) {
    ......
    }

    Allora puoi passare al metodo tanto un oggetto Libro quanto un Panino. Al metodo quasi sicuramente questo non interessa. Interesserà magari solamente che è un "vendibile" e che quindi potrà ottenere il prezzo con getPrezzo() e fare qualcosa.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  5. #5
    Originariamente inviato da gasparirob
    Si, ma perche ?
    ribadisco il concetto espresso da andbin

    mettiamo che tu voglia fare un programma "GarageBand" che abbia degli strumenti (tromba, batteria, chitarra) che devono essere suonati da un player, allora avrai che player deve avere un metodo differente per ogni strumento che gli passi, perchè di ogni strumento player dve sapere che metodo di quello strumento richiamare per fargli emettere un suono. Immaginati che tu voglia estendere il programma a tutti gli strumenti possibili e immaginabili, allora sto povero player avrà moltissimi metodi sostanzialmente tutti uguali eccetto che per l'oggetto passameto in parametro. na schifezz

    allora si applica un'interaccia agli strumenti che verrà implementata da ogni strumento

    codice:
    public interface Strumento{
    
      void suona();
    
    }
    
    
    public Chitarra implements Strumento{
    
       public void suona(){ System.out.println("zum-zum-zum");}
    
    }
    
    public Violino implements Strumento{
    
       public void suona(){System.out.println("zin-zin-zin");}
    
    }
    
    ...etc..
    e il nostro player dovrà semplicemente

    codice:
    public static void Main(String[] args)
    {
    
       Strumento chitarra=new Chitarra();
       Strumento violino=new Violino();
    
       this.playMusic(chitarra);
       this.palyMusic(violino);
    }
    
    public void playMusic(Strumento strumento)
    {
        strumento.suona();
    }
    nota che quindi oggetti che hanno in comune un dover fare qualcosa ma che il modo in cui lo fanno debba essere eseguito in maniera diversa a seconda dell'oggetto, possano essere riconducibili ad un'interfaccia che viene implementata ogni volta in maniera diversa.
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  6. #6
    AAHHHHHH!!!!!

    gia ci comincio a vedere piu chiaro... devo ancora capire bene quello che avete scritto, ma ho intuito il senso...

  7. #7
    Uno degli usi delle interfacce è quello di far sapere al mondo esterno che la tua classe ha determinate proprietà.

    Ad esempio se una classe implementa l'interfaccia Iterator tutti sapranno che avrà implementati i metodi hasnext(), next() e remove() .

    In questo senso le interfacce rappresentano un contratto. Se una classe implementa una interfaccia specifica tutti sapranno che rispetta quel contratto.
    VVoVe:

  8. #8
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Ci sarebbe anche un'altra questione da affrontare. E cioè il solito "dilemma" se usare la ereditarietà (estensione di una classe) o la implementazione di una interfaccia. Spiego meglio con degli esempi:

    Santino83_02 ha fatto un esempio che di per sé non è sbagliato. Ma bisogna ragionare un pochino. La prima cosa che si può notare è che Violino e Chitarra sono in effetti dei "casi" più specifici di uno strumento. Per tale motivo sarebbe stato più logico realizzare una gerarchia di classi del tipo:

    class Strumento { .... }
    class Chitarra extends Strumento { .... }
    class Violino extends Strumento { .... }


    Proviamo ora con i tipi che ho usato nel mio esempio (Vendibile/Libro/Panino). Ci si può chiedere: un libro è un caso più specifico di un vendibile??? Ehm ... già così la frase non avrebbe granché senso. Quindi non sarebbe particolarmente logico fare una classe Vendibile e poi estenderla.

    Morale della favola: si dovrebbe usare la ereditarietà (estensione di una classe) solo per la specializzazione, cioè per definire un tipo di più specifico rispetto alla super-classe e si dovrebbero usare le interfacce per definire un comportamento, una proprietà o in altre parole una "capacità" che più oggetti possono avere.

    Non per nulla nel framework di Java la maggior parte delle interfacce hanno il nome che termina in "-able", es. Cloneable, Comparable, Serializable. Cioè clonabile, comparabile, serializzabile ecc... Tutti termini che indicano una capacità di fare una certa cosa.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  9. #9
    non sono molto daccordo sull'estensione di una classe (che poi sarà astratta) strumento nei vari strumenti specializzati (piu che altro perchè poi chi glielo spiega al professore che deve cambiare le slide che fa vedere a lezione? ) cmq è certamente una cosa valida anche se continuo a pensare che nel caso specifico è meglio che uno strumento sia sotto contratto, piuttosto che estenda un'altra classe. Però è un caso, l'importante è capire il perchè si fanno le interfacce e perchè poi si vedrà come estendere un'altra classe e cosa comporta.
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  10. #10
    Quindi: (correggetemi se sbaglio)

    il punto chiave sta proprio nel metodo che accetta l'interfaccia come parametro. E' qui che l'interfaccia permettere di usare quel metodo senza dover creare tanti metodi a seconda del tipo di oggetto

    riprendendo gli esempi:

    public void playMusic(Strumento strumento)
    {
    strumento.suona();
    }

    e

    public boolean controllaPrezzo (Vendibile v) {
    ......
    }


    è proprio qui che l'interfaccia passata come parametro permette di dare un senso all'interfaccia stessa. Perche, in altra maniera, avrei potuto non usare l'interfaccia e poi definire tanti metodi playMusic e controllaPrezzo, a seconda del tipo di oggetto passato come parametro.


    Questo è quello che CREDO di aver capito...

    passiamo invece ad alcuni punti che non mi sono proprio chiari:
    Allora puoi passare al metodo tanto un oggetto Libro quanto un Panino. Al metodo quasi sicuramente questo non interessa. Interesserà magari solamente che è un "vendibile" e che quindi potrà ottenere il prezzo con getPrezzo() e fare qualcosa
    perche questa "insicurezza"?
    è possibile eliminare le parole in grassetto?

    Ad esempio se una classe implementa l'interfaccia Iterator tutti sapranno che avrà implementati i metodi hasnext(), next() e remove()
    ma tutti chi?


    Scusate per queste domande che sicuramente saranno banali... ma vorrei "fare mio" il concetto di interfaccia... anche se col tempo (e quindi programmando), la cosa, probabilmente, verrà da se...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.