Liste Type de rapport type ArrayList en Java

(1) List<?> myList = new ArrayList<?>();

(2) ArrayList<?> myList = new ArrayList<?>();

Je comprends que (1), les implémentations de la Liste interface peut être échangé. Il semble que (1) est généralement utilisé dans une application indépendamment du besoin (moi je l'utilise toujours).

Je me demandais si quelqu'un utilise (2)?

Aussi, combien de fois (et puis-je s'il vous plaît obtenir un exemple) la situation réellement besoin de l'aide des (1) (2) (c'est à dire où (2) ne suffira pas..à part codage des interfaces et meilleures pratiques etc.)

InformationsquelleAutor kji | 2010-02-17
  1. 409

    Presque toujours le premier est préféré au cours de la deuxième. La première a l'avantage de la mise en œuvre de la List peut changer (pour un LinkedList par exemple), sans affecter le reste du code. Ce sera une tâche difficile à faire avec un ArrayList, non seulement parce que vous aurez besoin de changer ArrayList à LinkedList partout, mais aussi parce que vous avez utilisée ArrayList des méthodes spécifiques.

    Vous pouvez lire sur List implémentations ici. Vous pouvez commencer avec un ArrayList, mais peu de temps après, de découvrir qu'une autre mise en œuvre est plus approprié.

    • pouvez-vous élaborer sur la modification de la mise en œuvre de la Liste? À l'aide de mon code comme un exemple, pour modifier maliste à une LinkedList, ne serait-on pas toujours besoin d'appeler new LinkedList() sur le maliste?
    • oh j'ai commenté votre dernier était plus là..mais il prend tout son sens maintenant..merci
    • Oui, et ce sera le seul changement de code dont vous aurez besoin. Comparer avec avec l'évolution de la liste de tableaux à LinkedList dans chaque méthode. Pour ne pas mentionner avoir à replaca une liste de tableaux seule méthode.
    • "mais aussi parce que vous avez utilisée ArrayList méthodes spécifiques" - n'est-ce pas un argument pour l'utilisation de la liste de tableaux? Si vous utilisez la Liste, vous ne pouvez pas utiliser ArrayList des méthodes spécifiques.
    • Les cas que vous avez besoin pour utiliser ArrayList méthodes spécifiques sont limitées. Dans ce cas, vous pouvez très facilement convertir votre Liste de liste de tableaux très facilement. La plus courante consiste à utiliser accidentellement une liste de tableaux de la méthode, sans que cela soit nécessaire. Modification de liste de tableaux à la Liste ou à un autre de la Liste de mise en œuvre est difficile.
    • Quelque chose à noter est que "ArrayList méthodes spécifiques" ne se limite pas aux méthodes utilisées dans l'ArrayList, mais leurs types de retour d'être changé (va provoquer une NoSuchMethodException entre les versions de Java si le type de retour de changements). Un exemple de cela est le changement dans le type de retour de keySet dans ConcurrentHashMap entre Java 7 et 8.
    • Alors pourquoi utiliser ArrayList ou LinkedList?
    • Je vois que la liste de variable est de type ArrayList. Pourquoi ne serait-il pas comme le C#, où vous avez une Liste<int> someVar = new List<int>() ?
    • pourquoi devrais-je le changer en LinkedList?
    • LinkedList est une autre Liste de mise en œuvre qui est mieux adapté dans certains cas, que ArrayList. Voir stackoverflow.com/questions/322715/...
    • Mais pourquoi n'avez-liste de tableaux de méthodes spécifiques si vous êtes juste de restreindre ses fonctionnalités, de toute façon?
    • C'est une mauvaise pratique que Java développeurs a ramassé. Il n'a pas de sens de perdre du béton type d'informations lorsque vous venez tout juste annoncé. Il n'est pas difficile de modification de la déclaration et d'autres devoirs. Et si je dois utiliser des fonctionnalités spécifiques à l'ArrayList cette Liste ne précise pas, j'ai déjà beaucoup plus à s'inquiéter que la modification de la déclaration et d'autres devoirs. Il est seulement bon pour la paresse lorsque vous essayez de mesure de la performance entre les différents types de collection. Je ne le ferais pas, dans le code de production si personne ne m'a forcé.

    InformationsquelleAutor kgiannakakis
  2. 107

    Je me demandais si quelqu'un utilise (2)?

    Oui. Mais rarement pour de bonnes raisons (OMI).

    Et les gens ont brûlé parce qu'ils ont utilisé ArrayList quand ils devraient avoir utilisé List:

    • Méthodes de l'utilitaire, comme Collections.singletonList(...) ou Arrays.asList(...) ne retourne pas une ArrayList.

    • Méthodes dans le List API ne garantit pas pour retourner une liste du même type.

    Par exemple de quelqu'un se brûler, en https://stackoverflow.com/a/1481123/139985 l'affiche avait des problèmes de "découpage" parce que ArrayList.sublist(...) ne retourne pas une ArrayList ... et il avait conçu son code à utiliser ArrayList que le type de l'ensemble de sa liste de variables. Il a fini par "résoudre" le problème en copiant le sous-liste dans une nouvelle ArrayList.

    L'argument que vous avez besoin de savoir comment le List se comporte est en grande partie résolues par l'utilisation de la RandomAccess interface marqueur. Oui, c'est un peu maladroit, mais l'alternative est pire.

    Aussi, combien de fois la situation réellement besoin de l'aide des (1) (2) (c'est à dire où (2) ne suffira pas..à part 'de codage pour les interfaces et les meilleures pratiques, etc.)

    La "combien de fois" partie de la question est, objectivement, sans réponse.

    (et puis-je s'il vous plaît obtenir un exemple)

    Occasionnellement, l'application peut exiger que vous utilisez des méthodes dans le ArrayList API qui sont pas dans le List API. Par exemple, ensureCapacity(int), trimToSize() ou removeRange(int, int). (Et le dernier, ne se posent que si vous avez créé un sous-type de liste de tableaux qui déclare la méthode à public.)

    C'est la seule bonne raison pour le codage de la classe plutôt que de l'interface, de l'OMI.

    (Il est théoriquement possible que vous obtiendrez une légère amélioration de la performance ... dans certaines circonstances ... sur certaines plates-formes ... mais à moins que vous vraiment besoin de ce dernier à 0,05%, il n'est pas en vaut la peine. Ce n'est pas une bonne raison, de l'OMI.)

    Vous ne pouvez pas écrire du code efficace si vous ne savez pas si d'accès aléatoire est efficace ou pas.

    Qui est un bon point. Cependant, Java fournit de meilleures façons de traiter avec que; par exemple,

    public <T extends List & RandomAccess> void test(T list) {
    //do stuff
}

    Si vous l'appelez avec une liste qui n'en œuvre RandomAccess, vous obtiendrez une erreur de compilation.

    Vous pouvez également tester dynamiquement ... à l'aide de instanceof ... si le typage statique est trop maladroit. Et vous pouvez même écrire votre code pour utiliser différents algorithmes (dynamiquement) en fonction de si oui ou non une liste soutenue de l'accès aléatoire.

    Noter que ArrayList n'est pas le seul de la liste de la classe qui implémente RandomAccess. D'autres incluent CopyOnWriteList, Stack et Vector.

    J'ai vu des gens faire le même argument à propos des Serializable (parce que List n'est pas mise en œuvre) ... mais l'approche ci-dessus résout ce problème aussi. (Dans la mesure où il est résoluble à tous les à l'aide d'exécution types. Un ArrayList échouera sérialisation si aucun élément n'est pas sérialisable.)

    InformationsquelleAutor Stephen C
  3. 37

    Par exemple, vous pourriez décider d'un LinkedList est le meilleur choix pour votre application, mais plus tard décider ArrayList pourrait être un meilleur choix pour des raisons de performances.

    Utilisation:

    List list = new ArrayList(100); //will be better also to set the initial capacity of a collection

    Au lieu de:

    ArrayList list = new ArrayList();

    Pour référence:

    Liste Type de rapport type ArrayList en Java

    (posté principalement pour la Collecte schéma)

    InformationsquelleAutor Maxim Shoustin
  4. 23

    Il est considéré comme bon style pour stocker une référence à un HashSet ou TreeSet dans une variable de type Ensemble.

    Set<String> names = new HashSet<String>();

    De cette façon, vous avez à changer une seule ligne si vous décidez d'utiliser un TreeSet à la place.

    Aussi, les méthodes qui fonctionnent sur des ensembles devraient spécifier les paramètres de type de Jeu:

    public static void print(Set<String> s)

    Puis la méthode peut être utilisée pour définir tous les implémentations.

    En théorie, nous devrions faire la même recommandation pour les listes liées, à savoir sauver des
    LinkedList références dans des variables de type Liste. Cependant, dans la bibliothèque Java, la Liste de l'interface est commune à la fois à l' ArrayList et la LinkedList classe. En particulier, il a des méthodes get et set pour un accès aléatoire, même si ces méthodes sont très inefficace pour les listes chaînées.

    Vous ne pouvez pas écrire du code efficace si vous ne savez pas si d'accès aléatoire est efficace ou pas.

    Ce n'est manifestement une grave erreur de conception dans la bibliothèque standard, et je ne peux pas recommander l'utilisation d'
    la Liste de l'interface pour cette raison.

    Pour voir juste comment embarrassant que l'erreur est, jetez un oeil à
    le code source de la binarySearch méthode de la Collections classe. Cette méthode prend un
    Paramètre de liste, mais la recherche binaire n'a pas de sens pour une liste liée. Le code puis maladroitement
    essaie de découvrir si la liste est une liste chaînée, et passe ensuite à une recherche linéaire!

    La Set de l'interface et la Map de l'interface, sont bien conçus, et vous devez les utiliser.

    • Upvoted pour dire précisément quel est le problème dans la clandestinité ArrayList vs LinkedList derrière la Liste.
    • Cela mérite plus upvotes. Effacé mon doute si je dois continuer à utiliser ArrayList ou de la Liste. Si je suis à la recherche de performance et je n'ai pas besoin d'un accès aléatoire, ArrayList est la réponse!
    • Notez cependant qu'il est un marqueur de l'interface appelée RandomAccess qui est appliqué à tous les types List sous-classes qui ont efficace de l'accès aléatoire. Par exemple ArrayList la met en œuvre, et LinkedList ne l'est pas. Vous pouvez utiliser cette option pour choisir entre les algorithmes qui nécessitent un accès aléatoire ou pas.
    InformationsquelleAutor nazar_art
  5. 12

    J'utilise (2) si le code est le "propriétaire" de la liste. C'est par exemple vrai pour les locaux-seules les variables. Il n'y a pas de raison d'utiliser le type abstrait List au lieu de ArrayList.
    Un autre exemple pour démontrer la propriété:

    public class Test {

    //This object is the owner of strings, so use the concrete type.
    private final ArrayList<String> strings = new ArrayList<>();

    //This object uses the argument but doesn't own it, so use abstract type.
    public void addStrings(List<String> add) {
        strings.addAll(add);
    }

    //Here we return the list but we do not give ownership away, so use abstract type. This also allows to create optionally an unmodifiable list.
    public List<String> getStrings() {
        return Collections.unmodifiableList(strings);
    }

    //Here we create a new list and give ownership to the caller. Use concrete type.
    public ArrayList<String> getStringsCopy() {
        return new ArrayList<>(strings);
    }
}
    • Que faire si vous vous décidez pour une raison que un LinkedList va fonctionner mieux qu'un ArrayList, vous auriez à changer la signature de l'évaluateur méthodes, qui signifie aussi la chose à l'aide de ces méthodes devront être examinés et éventuellement refait... qui peuvent chaîne tout le chemin jusqu'au plus haut niveau.
    • vous avez raté ce getStrings renvoie une List, plutôt que de ArrayList. Tout appelant qui devrait s'en occuper, le membre d'une manière abstraite, va utiliser ce accesseur.
    • Je faisais allusion à getStringsCopy() qui crée une copie de strings. strings est une variable interne, de sorte que vous pouvez changer autant de fois que vous en avez besoin pour répondre à l'évolution des besoins. Mais l'interface (les méthodes publiques) ne devrait pas changer si vous pouvez l'aider. Au retour d'une ArrayList les verrous de la classe à l'aide d'un ArrayList mise en œuvre, lorsque ArrayList est simplement un List l'utilisation de tableaux pour mettre en œuvre le comportement, de sorte qu'il n'a pas ajouté des fonctionnalités plus List à tous.
    • Je suis d'accord qu'il n'est généralement pas une bonne idée d'avoir des méthodes publiques de recevoir ou de retour de types de béton comme ArrayList. Mais @mazatwork a aussi un point avec son "propriétaire" de la définition. Si le propriétaire sait que la Liste doit être d'un certain type, alors il doit s'assurer que, et donc de la déclarer. Voir aussi ma réponse à propos de la Sérialisation
    InformationsquelleAutor mazatwork
  6. 11

    Lorsque vous écrivez List, vous fait dire que votre objet implémente List seulement l'interface, mais vous ne précisez pas quelle classe est votre objet appartient.

    Lorsque vous écrivez ArrayList, vous spécifiez que votre classe d'objet est un redimensionnable-tableau.

    Ainsi, la première version rend votre code plus souple à l'avenir.

    Regarder Java docs:

    La classe ArrayList Redimensionnable-tableau de mise en œuvre de la List interface.

    L'Interface List - Une collection ordonnée (aussi connu comme une séquence). L'utilisateur de cette interface a un contrôle précis où, dans la liste de chaque élément est inséré.

    Array - objet conteneur qui contient un nombre fixe de valeurs d'un type unique.

    InformationsquelleAutor wzbozon
  7. 9

    (3) de la Collection myCollection = new ArrayList();

    J'utilise habituellement. Et seulement si j'ai besoin de la Liste des méthodes, je vais utiliser la Liste. Même avec ArrayList. Vous pouvez toujours passer à plus "étroite" de l'interface, mais vous ne pouvez pas passer pour plus "large".

    • Est-ce une chose que les gens font? Par ce raisonnement, je devrais être à l'aide de l'Objet de partout. Je pense que très peu de modèles que de vagues assez pour avoir besoin d'utiliser l'interface de Collecte directement. Je vais supposer par les 8 upvotes d'au moins 7 autres personnes le faire...
    • Qui m'a fait rire 🙂 Mais c'est toujours un bon point!
    • J'attends avec impatience le jour où nos outils servira à examiner les méthodes (membres) sont utilisés, et dites-nous le plus étroit de déclaration qui comprend ces méthodes. MAIS si l'on puis essayez d'utiliser une méthode de portée plus large, va nous dire que nous pourrions utiliser cette méthode, si nous avons changé le type de variable.
    • Si une application a besoin de méthodes de l'interface de Collecte alors seulement c'est une solution acceptable. Et si une application utilise les méthodes de la classe Object alors seulement l'Objet o = <tout objet>; est une solution acceptable ainsi.
    InformationsquelleAutor Pavel Vyazankin
  8. 9

    Je pense que les gens qui les utilisent (2) ne sait pas le Principe de substitution de Liskov ou la Inversion de dépendance principe. Ou qu'ils ont vraiment à utiliser ArrayList.

    InformationsquelleAutor True Soft
  9. 9

    En fait, il ya des occasions où (2) n'est pas seulement souhaitable, mais obligatoire et je suis très surpris que personne n'en parle ici.

    Sérialisation!

    Si vous avez une classe sérialisable et vous voulez pour contenir une liste, vous devez déclarer le terrain, de béton et serializable type comme ArrayList parce que le List interface ne s'étend pas java.io.Serializable

    Évidemment, la plupart des gens n'ont pas besoin de sérialisation et de l'oublier.

    Un exemple:

    public class ExampleData implements java.io.Serializable {

//The following also guarantees that strings is always an ArrayList.
private final ArrayList<String> strings = new ArrayList<>();
    • Dans la pratique, rares sont les cas où vous avez besoin de savoir lors de la compilation que la mise en œuvre de la classe d'une variable implémente Serializable. Et lorsque vous le faites, vous pouvez faire quelque chose comme ceci: public <T extends List & Serializable> void test(T list) { ... }.
    InformationsquelleAutor raudi
  10. 7

    De deux suivantes:

    (1) List<?> myList = new ArrayList<?>();

(2) ArrayList<?> myList = new ArrayList<?>();

    Première est généralement préféré. Comme vous allez être en utilisant des méthodes de List seulement l'interface, il vous offre la liberté d'utiliser certains autres de la mise en œuvre de List par exemple LinkedList à l'avenir. Donc, il dissocie vous de mise en œuvre spécifiques. Maintenant, il y a deux points qui méritent une mention particulière:

    1. Nous devrions toujours programme d'interface. Plus ici.
    2. Vous aurez presque toujours à l'aide de ArrayList sur LinkedList. Plus ici.

    Je me demandais si quelqu'un utilise (2)

    Oui parfois (rarement lu). Lorsque nous avons besoin de méthodes qui font partie de la mise en œuvre de ArrayList mais ne faisant pas partie de l'interface List. Par exemple ensureCapacity.

    Aussi, combien de fois (et puis-je s'il vous plaît obtenir un exemple) la situation
    effectivement besoin de l'aide des (1) (2)

    Presque toujours vous préférez l'option (1). C'est un classique du design pattern en programmation orientée objet, où vous essayez toujours de dissocier votre code d'spécifiques de mise en œuvre et le programme de l'interface.

    InformationsquelleAutor i_am_zero
  11. 3

    Liste est une interface.Il n'a pas de méthodes. Lorsque vous appelez la méthode sur une Liste de référence. En fait, elle appelle la méthode de la liste de tableaux dans les deux cas.

    Et pour le futur, vous pouvez modifier List obj = new ArrayList<> à List obj = new LinkList<> ou d'un autre type qui implémente Liste de l'interface.

    • Vous devriez le dire autrement : la Liste a de la méthode, mais ils ne sont pas mis en œuvre Vous ne dites pas "Il n'a pas de méthodes."
    InformationsquelleAutor Xar-e-ahmer Khan
  12. 3

    Quelqu'un a demandé à ce nouveau (double) qui m'a fait aller un peu plus loin sur cette question. 

    public static void main(String[] args) {
    List<String> list = new ArrayList<String>();
    list.add("a");
    list.add("b");

    ArrayList<String> aList = new ArrayList<String>();
    aList.add("a");
    aList.add("b");

}

    Si nous utilisons un bytecode viewer (j'ai utilisé http://asm.ow2.org/eclipse/index.html) weĺl voir la suite (seulement la liste d'initialisation et affectation) pour notre liste extrait de:

       L0
    LINENUMBER 9 L0
    NEW ArrayList
    DUP
    INVOKESPECIAL ArrayList.<init> () : void
    ASTORE 1
   L1
    LINENUMBER 10 L1
    ALOAD 1: list
    LDC "a"
    INVOKEINTERFACE List.add (Object) : boolean
    POP
   L2
    LINENUMBER 11 L2
    ALOAD 1: list
    LDC "b"
    INVOKEINTERFACE List.add (Object) : boolean
    POP

    et pour accédez à la liste:

       L3
    LINENUMBER 13 L3
    NEW java/util/ArrayList
    DUP
    INVOKESPECIAL java/util/ArrayList.<init> ()V
    ASTORE 2
   L4
    LINENUMBER 14 L4
    ALOAD 2
    LDC "a"
    INVOKEVIRTUAL java/util/ArrayList.add (Ljava/lang/Object;)Z
    POP
   L5
    LINENUMBER 15 L5
    ALOAD 2
    LDC "b"
    INVOKEVIRTUAL java/util/ArrayList.add (Ljava/lang/Object;)Z
    POP

    La différence est liste finit par appeler INVOKEINTERFACE alors que accédez à la liste appels INVOKEVIRTUAL. Accoding à la Bycode Contour Plugin de référence,

    invokeinterface est utilisé pour appeler une méthode déclarée dans une Java
    interface

    tout invokevirtual

    appelle toutes les méthodes à l'exception de l'interface des méthodes (qui utilisent des
    invokeinterface), les méthodes statiques (qui utilisent invokestatic), et les quelques
    cas particuliers traités par invokespecial.

    En résumé, invokevirtual pop objectref hors de la pile alors que pour invokeinterface

    l'interprète pop 'n' objets sur la pile d'opérande, où 'n' est un 8 bits non signé
    paramètre entier pris à partir du bytecode. Le premier de ces éléments est
    objectref, une référence à l'objet dont la méthode est appelée.

    Si je comprends bien, la différence est fondamentalement la façon dont chaque chemin récupère objectref.

    • Ermm ... cette analyse est discutable. En réalité, le compilateur JIT effectue une analyse globale afin de déterminer si les appels de méthode devez faire virtuel (dispatching) les appels de méthode. Beaucoup de / la plupart des INVOKEVIRTUAL instructions bytecode se transformer en non-envoi d'appel de séquences au niveau du code natif.
    InformationsquelleAutor toxicafunk
  13. 2

    Le seul cas que je connaisse où (2) peut être mieux, c'est lors de l'utilisation de GWT, parce qu'il réduit la demande de l'empreinte (pas mon idée, mais le google web toolkit de l'équipe qui l'affirme). Mais pour les java s'exécutant à l'intérieur de la JVM (1) est sans doute toujours mieux.

    InformationsquelleAutor Hans Westerbeek
  14. 1

    Je dirais que 1 est préféré, à moins que

    • vous êtes en fonction sur la mise en œuvre de comportement en option* dans la liste de tableaux, dans ce cas explicitement à l'aide de ArrayList est plus clair
    • Vous serez à l'aide de la liste de tableaux dans un appel de méthode qui nécessite ArrayList, peut-être pour facultatif comportement ou les caractéristiques de performance

    Ma conjecture est que dans 99% des cas vous pouvez vous en tirer avec une Liste, qui est préféré.

    • par exemple removeAll, ou add(null)
    InformationsquelleAutor extraneon
  15. 1

    List interface ont plusieurs classes différentes - ArrayList et LinkedList. LinkedList est utilisée pour créer des collections indexées et ArrayList - créer des listes triées. Ainsi, vous pouvez utiliser l'une dans vos arguments, mais vous pouvez permettre à d'autres développeurs qui utilisent votre code, bibliothèque, etc. pour utiliser différents types de listes, non seulement que vous utilisez, ainsi, dans cette méthode

    ArrayList<Object> myMethod (ArrayList<Object> input) {
   //body
}

    vous pouvez l'utiliser uniquement avec ArrayList, pas LinkedList, mais vous pouvez vous permettre d'utiliser tout de List classes sur d'autres lieux où la méthode est à l'aide, c'est juste votre choix, en utilisant une interface peut permettre:

    List<Object> myMethod (List<Object> input) {
   //body
}

    Dans cette méthode, les arguments que vous pouvez utiliser n'importe quel de List les classes que vous souhaitez utiliser:

    List<Object> list = new ArrayList<Object> ();

list.add ("string");

myMethod (list);

    CONCLUSION:

    Utiliser les interfaces partout quand c'est possible, de ne pas restreindre vous ou d'autres personnes à utiliser les différentes méthodes qui ils veulent utiliser.

    InformationsquelleAutor Acuna