https://mletkin.net/index.php?action=history&feed=atom&title=Streams%3A_Lokale_Variablen 2026-05-19T16:43:02Z Versionsgeschichte dieser Seite in MimiPedia MediaWiki 1.39.4 https://mletkin.net/index.php?title=Streams:_Lokale_Variablen&diff=114&oldid=prev 2023-03-09T17:20:45Z

<p>Die Seite wurde neu angelegt: „<a href="/index.php?title=Kategorie:Java&amp;action=edit&amp;redlink=1" class="new" title="Kategorie:Java (Seite nicht vorhanden)">Category:Java</a> Beim Streunen durch den Code auf der Suche nach refakturierungswürdigen Häufchen stieß ich auf diese Methode: {{java|code= ControllerResul…“</p> <p><b>Neue Seite</b></p><div>[[Category:Java]]<br /> Beim Streunen durch den Code auf der Suche nach refakturierungswürdigen Häufchen stieß ich auf diese Methode:<br /> {{java|code=<br /> ControllerResult addAccounts(List&lt;Account&gt; accounts) {<br /> AccountCreator creator = new AccountCreator();<br /> List&lt;AccountCreationResult&gt; accountList = accounts.stream() //<br /> .map(creator::create) //<br /> .collect(Collectors.toList());<br /> return ControllerResult.result(Status.CREATED).entity(accountList);<br /> }<br /> }}<br /> Für jedes {{java|Account}}-Objekt der Liste wird – mit Hilfe des {{java|AccountCreator}}-Objekts ein Konto angelegt.<br /> Dessen {{java|create}}-Methode liefert für jeden Account ein {{java|AccountCreationResult}}-Objekt, das das Ergebnis der Anlage beschreibt. Die Ergebnisse werden gesammelt und als Liste zurückgegeben. Soweit, so einfach.<br /> <br /> Ich will nicht sagen, daß lokale Variablen grundsätzlich von Übel sind, aber jede Zeile Code die man löschen kann<br /> ohne die Lesbarkeit zu gefährden ist ein Gewinn. Warum also wird hier überhaupt eine lokale Variable verwendet?<br /> Das konventionelle Konstrukt – ohne Stream – sähe so aus:<br /> {{java|code=<br /> ControllerResult addAccounts(List&lt;Account&gt; accounts) {<br /> AccountCreator creator = new AccountCreator();<br /> List&lt;AccountCreationResult&gt; accountList = new ArrayList&lt;&gt;();<br /> for (Account account : accounts) {<br /> accountList.add(creator.create(account));<br /> }<br /> return ControllerResult.result(Status.CREATED).entity(accountList);<br /> }<br /> }}<br /> Offensichtlich ist es sinnvoller, das {{java|Creator}}-Objekt nur einmal &#039;&#039;vor&#039;&#039; dem Eintritt in die Schleife zu erzeugen<br /> und dann bei jedem Durchlauf wiederzuverwenden, statt für jeden Account einen eigenen Creator zu erzeugen. Wie aber sieht<br /> das mit der Stream-Lösung aus? Betrachten wir dazu den schematischen Ablauf wenn die Stream-Anweisungen ausgeführt werden:<br /> {{java|code=accounts.stream()}}<br /> erzeugt ein neues Stream-Objekt mit einer leeren Liste von Anweisungen, die für jedes Objekt im Stream ausgeführt werden sollen.<br /> {{java|code=.map(creator::create)}}<br /> fügt der Anweisungsliste eine Anweisung hinzu, die den {{lambda}}-Ausdruck {{java|creator::create}} enthält. Das ist ein<br /> Verweis auf die Methode {{java|create()}} des Objektes, das in der lokalen Variable {{java|creator}} steckt.<br /> {{java|code=.collect(Collectors.toList())}}<br /> führt eine Schleife aus, die auf jedem Objekt des Streams die Anweisungen der Liste ausführt, die entstehenden<br /> Ergebnisse in einer Liste sammelt und diese als {{java|List}}-Objekt zurückgibt.<br /> Die Behauptung, daß das Stream-Objekt eine Anweisungsliste enthält ist extrem vereinfacht ausgedrückt, ist aber –<br /> was den Ablauf angeht – eine ausreichende Beschreibung. Der entscheidende Punkt ist, daß die Methode {{java|map()}}<br /> hier nur ein einziges Mal ausgeführt wird, und zwar bevor die Schleife über die Stream-Objekte ausgeführt wird.<br /> Schreiben wir also:<br /> {{java|code=<br /> ControllerResult addAccounts(List&lt;Account&gt; accounts) {<br /> List&lt;AccountCreationResult&gt; accountList = accounts.stream() //<br /> .map(new AccountCreator(session)::create) //<br /> .collect(Collectors.toList());<br /> return ControllerResult.result(Status.CREATED).entity(accountList);<br /> }<br /> }}<br /> dann wird tatsächlich – mit dem Debugger leicht nachzuvollziehen – auch nur einziges {{java|AccountCreator}}-Objekt<br /> erzeugt. Die Objekt-Referenz wird dabei scheinbar nirgendwo gespeichert. Scheinbar deshalb, weil sie natürlich implizit im {{lambda}}-Ausdruck<br /> {{java|code=new AccountCreator(session)::create}}<br /> enthalten ist. Wir können also tatsächlich auf die lokale Variable verzichten und das {{java|AccountCreator}}-Objekt<br /> on-the-fly beim Erzeugen des {{lambda}}-Ausdrucks instantiieren.<br /> Nun mag der Lambda-Neuling annehmen, daß die {{java|::}}-Notation des Ausdrucks nur syntaktischer Zucker ist und sich<br /> der Ausdruck auch so schreiben ließe:<br /> {{java|code=(Account a) -&gt; new AccountCreator(session).create(a);}}<br /> Achtung! Hier passiert etwas völlig anderes, denn wenn wir diesen {{lambda}}-Ausdruck in unserem Stream<br /> verwenden wird tatsächlich für jedes Stream-Objekt ein neues Creator-Objekt erzeugt, denn jetzt ist die Objekt-<br /> Erzeugung mit {{java|new}} Teil des {{lambda}}-Ausdrucks geworden. Warum ist das so?<br /> <br /> Für den {{lambda}}-Ausdruck<br /> {{java|code=(Account a) -&gt; new AccountCreator(session).create(a);}}<br /> wird ein Objekt einer anonymen Klasse erzeugt mit einer anonymen Methode, deren Body den Ausdruck rechts<br /> des {{java|-&gt;}}-Operators enthält. Beim Ausführen des {{lambda}}-Audrucks wird nun diese Methode dieses<br /> Objekts – die eine neues {{java|AccountCreator}}-Objekt erzeugt – ausgeführt. Für den {{lambda}}-Ausdruck<br /> {{java|code=new AccountCreator(session)::create}}<br /> hingegen wird ein Objekt der Klasse {{java|AccountCreator}} erzeugt die die Methode {{java|create}} implementiert.<br /> Bei der Ausführung des {{lambda}}-Ausdrucks wird die Methode {{java|create}} dieses Objekts ausgeführt und es wird kein<br /> neues {{java|AccountCreator}}-Objekt erzeugt.</div>

Ullrich