spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »DeKugelschieber«

Am besten finde ich die class Klasse{run()...} Dinger. Eine Methode.

Hängt vom Zusammenhang ab. Wenn so ein Runnable in unterschiedlichen anderen Klassen verwendet wird, würde ich es auch in eine eigene Java-Datei packen. Ansonsten als private Klasse unten an die ausführende dranpappen.

Was ist denn an Runnables unsauber? Du implementierst ein Interface, was es dir erlaubt, Code einfach und schnell in einem anderen Thread auszuführen.

Unsauber finde ich das nicht.

Ich bin auch kein Fan von diesem Runnable Klassen. Java bietet aber Anonyme Klassen und seit Java 8 auch Lambdas um Run Funktionen direkt dort zu definieren wo sie benutzt werden. Das wird natürlich dann hässlich, wenn man eine sehr komplexe Run Funktion hat. Aber dann macht es eh Sinn die Logik auszulagern und in der Run Funktion nur eine andere Funktion aufzurufen. Diese Funktion ist dann auch genau so wiederverwendbar wie eine Runnable Klasse.

Es kommt halt wie in jeder Sprache darauf an wie man sie verwendet. Und da ist leider auch mein Eindruck, dass in vielen Unternehmen ein eher gruseliger Stil herrscht, der oft darauf basiert das die gewählte Sprache nur grob beherrscht wird und entsprechend falsche Konstrukte gewählt werden.

Zitat von »Tobiking«

Aber dann macht es eh Sinn die Logik auszulagern und in der Run Funktion nur eine andere Funktion aufzurufen. Diese Funktion ist dann auch genau so wiederverwendbar wie eine Runnable Klasse.

Aber nur dann, wenn dafür keine zusätzlichen Daten benötigt werden. Wenn Daten gecaptured werden müssen, ist eine Runnable-Klasse plötzlich sehr sinnvoll.

Ich hab mir den Code nicht angeschaut. Folgende Formalitäten sind mir aufgefallen:

In Java hat sich mit Maven eine Standard-Projektstruktur etabliert:
src/main/java Application/Library sources
src/main/resources Application/Library resources
src/test/java Test sources
src/test/resources Test resources
(siehe http://maven.apache.org/guides/introduct…ory-layout.html, http://gradle.org/docs/current/userguide…gle.html#N103DE)

In einem professionellen Java-Projekt erwarte ich die Nutzung eines Buildtools mit Dependency-Management.

Bei den Tests halte ich die Paketierung nach Tool für fragwürdig. Ich würde sowas eher nach Feature machen, dann hat man alle Tests zu dem Feature auf einem Blick.

Zitat von »DeKugelschieber«

Mein Beispiel bezog sich nicht auf Runnables, sondern auf einfache Klassen die irgendwie Teil einer Prozesskette sind.

Ich glaube das liegt daran, dass man besonders als Hobby-C++-Entwickler eher zu einem imperativen Programmierparadigma neigt. Ausgeprägtes OOP wirkt dann erst mal unübersichtlich. Sobald eine Anwendung und das Entwicklerteam aber einen gewissen Rahmen sprengen skaliert OOP als Paradigma IMO wesentlich besser.

Vielleicht kannst Du mit dem Buch in diesem Zusammenhang etwas anfangen: [amazon]0321125215[/amazon]

PS: Der Link erscheint irgendwie doppelt

Stimmt, er ist doppelt, aber nicht derselbe Link. Einmal Buch und einmal eBook. Weird.