Je ne ressens pas la différence entre les méthodes map() et mapToObj() dans les flux Java 8. Dans les deux, nous pouvons créer et renvoyer des objets dans les flux, alors pourquoi ces méthodes existent en deux, et non en une seule.
Pourriez-vous me donner l'explication avec des exemples?
Vous verrez ce motif cool. L' Stream cours comprend un IntStream, LongStream, DoubleStream etc. Ceci est fait de sorte que vous pouvez utiliser les types primitifs dans les cours d'opérations. Parce que sinon, vous devez utiliser Stream<Integer> ou Stream<Double>, ce qui permettra de cocher les valeurs.
De même, l' map méthodes aussi le faire. Dans l' Stream<T> classe, il y a mapToInt, mapToDouble méthodes, mais la situation est un peu différente dans l' IntStream, DoubleStream les classes.
En IntStream, l' map méthode prend un IntUnaryOperator, qui associe à un entier de type int. Si vous souhaitez mapper le flux à un Stream<T>, vous devez utiliser mapToObj. mapToObj est un bon nom, car il distingue de l' map que des cartes à ints. Cela signifie que les modifications de flux à partir d'un IntStream d'un Stream<T>. La raison pourquoi mapToObj est nommé ainsi est la même raison pourquoi mapToInt est nommé ainsi à signifier un changement dans l' Stream type/
L' primitive et object versions de types de données (c'est à dire de type int et Entier, double et Double, etc.) ne sont pas vraiment compatibles les uns avec les autres en Java. Ils sont compatibles par l'étape supplémentaire de l' auto-boxing/unboxing. Ainsi, si vous avez un flux de primitives ints et si vous essayez d'utiliser l'objet de versions de Flux et de la Fonction (c'est à dire de Flux et de la Fonction, vous devrez payer le coût de la boxe et de déballer les éléments.
Pour éliminer ce problème, la fonction package contient primitive specialized versions of streams ainsi que functional interfaces. Par exemple, au lieu d'utiliser Stream<Integer>, vous devez utiliser IntStream. Vous pouvez maintenant traiter chaque élément du flux à l'aide IntFunction. Cela permettra d'éviter l'auto-boxing/unboxing tout à fait.
Ainsi, chaque fois que vous voulez traiter des flux de primitives éléments, vous devez utiliser la primitive spécialisés cours d'eau (c'est à dire IntStream, LongStream, et DoubleStream) et primitif spécialisé interfaces fonctionnelles (c'est à dire IntFunction, IntConsumer, IntSupplier etc.) pour obtenir de meilleures performances.
Une chose à noter est que aucun des primitives spécialisé interfaces fonctionnelles (telles que IntFunction, DoubleFunction, ou IntConsumer) prolonger la période de non-primitive d'interfaces fonctionnelles (c'est à dire de la Fonction, de la Consommation, et ainsi de suite).
java.util.function package contient int, double et long (mais pas de float) les versions de toutes les interfaces fonctionnelles. Par exemple, il y a un IntFunction, un DoubleFunction, et un LongFunction, qui sont de type int, double et long, les versions de la Fonction. Ces fonctions sont utilisés ainsi que les primitives des versions spécialisées de flux de IntStream, DoubleStream, et LongStream.
Prenons quelques exemples:
Stream stream = Stream.of(1, 2, 3); //Will compile fine
IntStream intStream = IntStream.of(4, 5, 6); //Will compile fine
Stream s = IntStream.of(4, 5, 6); //Does not compile
Stream s = IntStream.of(4, 5, 6).mapToObj(e -> e); //mapToObj method is needed
IntStream is = Stream.of(4, 5, 6).mapToInt(e -> e); //mapToInt method is needed
En conclusion, la raison, vous pouvez utiliser mapToObj est le même que vous pouvez utiliser mapToInt, ce qui est de changer le type de Flux.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
