Dungeon: improve readability by replacing implicit filtering (entityStream) with explicit filtering (filteredEntityStream, both System) #1564
Conversation
There was a problem hiding this comment.
@AMatutat An sich passt das. Bei zwei Sachen bin ich gestolpert und habe einen Vorschlag angetüdelt. Schau mal, ob das Sinn ergibt (ich hänge hier grad zwischen den Meetings - kann auch kompletter Nonsense sein).
@Flamtky Du hast ja auch viel mit entityStream gearbeitet. Wenn wir diesen PR jetzt mergen, macht Dir das ggf. das Leben schwerer, also sollten wir noch auf die vollständige Integration vom DevDungeon warten mit diesem PR?
cagix
changed the title
System#entityStream
Hatte irgendwie keine Benachrichtigung erhalten 😅. Also ich muss sowieso im DevDungeon viel anpassen, da ich schon bereits vieles geändert habe. Somit kann das hier gemergt werden. Die IDE sollte mir ja alles markieren wo es Probleme macht durch die neuen Methodennamen. |
@Flamtky okay, dann mache ich hier zu - ich wollte dir nur den job nicht noch schwerer machen, als er eh schon ist .) |
…CameraComponent) see #1564 (comment)
…pikeSystem) (#1567) see #1564 (comment) In ```java public void execute() { filteredEntityStream(SpikyComponent.class) .forEach(e -> e.fetch(SpikyComponent.class).orElseThrow().reduceCoolDown()); } ``` wird ein Stream aller Entitäten mit einer `SpikyComponent` vom `System` angefordert. Bei der Iteration über diese Entitäten wird dann (a) die `SpikyComponent` extrahiert, (b) eine Exception geworfen im Nichtvorhandensein-Fall, und (c) auf der Component eine Methode aufgerufen. Dies ist aus zwei Gründen problematisch: Zum werden mehrere Operationen in die `forEach`-Schleife verpackt, und zum anderen sollte man keine Exceptions in einer Stream-Operation werfen. (OK, das dürfte hier in der Realität auch nie passieren, da wir ja vorher exakt nach der Component gefiltert hatten. Dennoch.) Dieser PR führt ein Refactoring durch und erledigt **in jedem Stream-Step eine Sache**. Außerdem wird **keine Exception** mehr in der Stream-Verarbeitung geworfen, sondern Entitäten, die zwischen `System#filteredEntityStream` und dem `forEach` auf geheimnisvolle Weise ihre `SpikyComponent` verloren haben sollten, werden einfach ignoriert. Keine Änderung der API und/oder des Verhaltens.
fixes #1553
Überarbeitet den Umgang mit dem Entity-Stream in
System#execute-Methoden, um eine bessere Code-Lesbarkeit zu erreichen.Anmerkung: Durch die gemachten Änderungen kommt es zu Redundanz im Hinblick auf die Filterregeln. Diese werden weiterhin im System gespeichert, können jetzt aber optional als Parameter eigenständig verwendet werden. Wenn sich für das eigenständige Verwenden als Parameter entschieden wird, muss bei Änderungen an den Filtern darauf geachtet werden, diese überall einzutragen (im Konstruktor UND in der Execute-Funktion).
Für leichtere Bedienung und Abwärtskompatibilität ist die alte Variante aber weiterhin verfügbar.
Änderungen im Überblick:
System#entityStreaminSystem#filteredEntityStreamSystem#filteredEntityStreamin zwei Geschmacksrichtungen:filteredEntityStream(final Class<? extends Component>... filterRules)filteredEntityStream(Set<Class<? extends Component>> filterRules)System#filteredEntityStream(final Class<? extends Component>... filterRules)in dencore- undcontrib-SystemenACHTUNG: Veränderung der API. (keine Verhaltensänderung)