J'aimerais obtenir l'article après la dernière occurrence de l'élément spécifique de la liste. E.G.
List<Bean> list = ArrayList<Bean>() {{ add(new Bean(1, null)); // null add(new Bean(2, "text2")); add(new Bean(3, "text3")); add(new Bean(4, "text4")); add(new Bean(5, null)); // null last occurence add(new Bean(6, "text6"); // want this one. }}
7 Réponses :
Comme il a été mentionné dans les commentaires, les flux ne sont pas une bonne solution pour cette tâche. Mais il est toujours possible de faire avec eux avec atomic code>:
" Les flux ne sont pas une bonne solution pour cette tâche. Mais il est toujours possible de les faire avec Atomic: i>" - votre exemple n'utilise pas de flux.
@Slaw Vous avez raison, j'ai raté le point .foForeach () code> est également présent dans
itérable code>. Merci!
Je suis avec Realskeptic sur les flux de ne pas être le meilleur pour ce problème. Si vous devez le faire, cependant, vous pouvez itérer sur votre liste en sens inverse, filtrer pour trouver le premier texte NULL, puis choisissez celui qui vous a précédé.
Il est plus pratique avec un flux d'indices plutôt que le flux d'éléments de liste:
sans flux: Vous pouvez également itérer la liste en sens inverse, à l'aide d'un lisiterator (code> et arrêtez dès que vous trouverez le premier match. p> p>
L'une des solutions de contournement pour l'utilisation du flux code> code> serait de garder une trace du dernier index du texte code> S de haricot code>.
OptionalInt lastIndex = IntStream.range(0, list.size())
.filter(ix -> list.get(ix).getText() == null)
.reduce((a, b) -> b);
Remarque - list.get.get (NULL) + 1) CODE> Pourriez vous obtenir Aioobe, au cas où vous recherchez un texte également là-bas pour un haricot comme dernier élément de l'entrée.
C'est beaucoup d'évaluations d'informations non désirées. Pourquoi pas facultatifint O = intSTetream.range (0, liste.Size ()) .Filter (ix -> list.get.get (ix) .getext () == null) .Reduce (a, b) -> b) .MAP (IX -> IX + 1); code>?
@Holger J'ai fait cela exprès, pour être honnête, compte tenu des cas d'utilisation qui pourraient être construits sur elle. Je comprends que cela apporte beaucoup d'informations, mais l'idée de diverger à partir de l'approche code> itératrice code> consistait à fournir des recherches pour les autres chaînes sans plus itération. Merci pour la suggestion, je voudrais toujours adapter tout cela dans la réponse.
Une autre solution est la suivante: version du flux: p>
Utiliser Ceci repose sur des éléments positionnés . Cela jette un Alternativement, au lieu de partitionnementde code>
. NosuchelementException code> ou un
arrayindexoutofboundSException code> si cet élément n'existe pas. P>
+ 1 code>, vous pouvez aussi faire simplement faire
.maptoobj (i -> i + 1) code> au lieu de
.Boxed () code>, ce qui donne les mêmes résultats. sup > p> p>
Je commencerais simplement à la fin et au travail en arrière. Notez que cela commence sur le dernier élément du dernier élément. Si le dernier élément était null, il n'y aurait rien à retourner.
La manipulation du dernier élément reste floue basée sur la question. mais pour noter, avec cette solution, le si null code> en tant que texte faisait partie de deux
haricot code> S, un à 2ème index et un autre au dernier index, cela imprimerait la troisième élément. (Peu importe que l'on puisse s'attendre à ce qu'il soit "rien trouvé")
Qu'est-ce qui serait retourné si vous avez appelé getafterlast (nouveau haricot (6, "text6"))?
Les flux ne sont pas une bonne solution pour cela. Cela nécessite de regarder en avant (pour voir quel élément est "Dernier"), en regardant autour de (pour voir "article après"). Les flux ne doivent être utilisés que lorsqu'ils ont un sens et que le code n'est pas trop compliqué - ce qui signifie généralement appliquer des opérations à chaque élément (filtre, carte, etc.) sans contexte.
Utilisez un itérateur plutôt qu'un flux. Étant donné que vous avez une exigence de commande évidente, il n'y a aucun avantage à utiliser des flux sur une simple itération.
Au fait: N'utilisez pas l'initialiseur double-brace i> b> (qui n'existe pas en réalité par la voie). Voici plus à ce sujet .