Visualizzazione dei risultati da 1 a 4 su 4
  1. #1

    tipo1 ciao = new tipo2() - qual'è il vantaggio?

    Salve, ad esempio potrei scrivere:

    codice:
    List<String> ciao= new ArrayList<String>();
    Istanzio cioè un oggetto di tipo ArrayList ma lo metto in un riferimento di tipo List (che dovrebbe essere una superclasse...giusto?).
    In questo modo uso i metodi della superclasse...non quelli di ArrayList.
    che vantaggio ne posso trarre? Ovvero quali sono le differenze rispetto a:

    codice:
    List<String> ciao= new List<String>();
    oppure:

    codice:
    ArrayList<String> ciao= new ArrayList<String>();

    grazie a tutti
    IDE: NetBeans 7.1
    Java:1.7.0_2
    Framework: JSF 2.0/2.1 - Mojarra 2.1.3
    Primefaces 3.2
    GlassFish 3.1.2

  2. #2
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157

    Re: tipo1 ciao = new tipo2() - qual'è il vantaggio?

    Originariamente inviato da supertarmax
    Salve, ad esempio potrei scrivere:

    codice:
    List<String> ciao= new ArrayList<String>();
    Istanzio cioè un oggetto di tipo ArrayList ma lo metto in un riferimento di tipo List (che dovrebbe essere una superclasse...giusto?).
    in realtà List è una interfaccia, questa dicitura serve a dichiarare che vuoi un tipo che sia in grado di fare determinate cose. Le cose che pretendi siano fatte le indichi con l'interfaccia (quindi vuoi un tipo su cui puoi fare add, remove, get ecc).
    L'interfaccia (come sai) non può essere istanziata, quindi l'istanziazione la fai con una implementazione di List (che è appunto ArrayList).

    se guardi qui hai le API di List e l'elenco delle sue implementazioni.
    Il vantaggio reale lo hai quando usi List come parametro di un metodo, in questo modo stai implicitamente dicendo "non importa quale implementazione fornisci, mi basta che mi dai qualcosa che sia in grado di soddisfare l'interfaccia".

    In questo modo uso i metodi della superclasse...non quelli di ArrayList.
    che vantaggio ne posso trarre? Ovvero quali sono le differenze rispetto a:
    Originariamente inviato da supertarmax
    codice:
    List<String> ciao= new List<String>();
    non valido perché List è una interfaccia

    Originariamente inviato da supertarmax
    oppure:

    codice:
    ArrayList<String> ciao= new ArrayList<String>();

    grazie a tutti
    qui usi direttamente l'implementazione, ti ho detto sopra la differenza.
    Qualora dovessi usare la tua lista dentro una classe (membro private quindi) e non la usi mai come parametro di qualche metodo allora le due diciture sono equivalenti, potresti usare la seconda per sfruttare a pieno i metodi tipici di ArrayList (senza dover fare cast).
    Quando uso Collection io preferisco sempre la prima dicitura (ma è una cosa personale)
    RTFM Read That F*** Manual!!!

  3. #3
    sempre chiarissimo
    grazie
    IDE: NetBeans 7.1
    Java:1.7.0_2
    Framework: JSF 2.0/2.1 - Mojarra 2.1.3
    Primefaces 3.2
    GlassFish 3.1.2

  4. #4
    Il vantaggio di usare una interfaccia invece del tipo istanziato è di nascondere agli utilizzatori del tuo oggetto "ciao" dettagli implementativi che possono cambiare nel tempo.
    Per esempio potresti voler sostituire l'arraylist con una linkedlist o una lista sincronizzata, in questo modo dovresti cambiare solo il pezzo di codice in cui istanzi l'oggetto.
    La pratica normalmente è redditizia in fase di manutenzione e per l'information hiding, ma presenta delle criticità qualora il codice abbia dei tempi di esecuzione critici in quanto l'uso del polimorfismo presenta un piccolo overhead che può rivelarsi fatale nel codice in real time.
    Diciamo che 99% dei casi, soprattutto rimanendo in ambito gestionale, l'uso dell'interfaccia sarebbe preferibile mentre in quei pochi casi che sarà da evitare potrai sempre intervenire per affinamenti successivi.
    ...

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.