R
Jester schrieb:
Die Abläufe sind größtenteils unabhängig voneinander. Nur an wenigsten Stellen müssen die Aufgaben synchronisiert werden. Also ist es doch eigentlich natürlicher das als Thread zu strukturieren, als es künstlich in einen festen Ablauf reinzudrücken, der rein künstlich ist.
Sachen auf Threads aufzuteilen ist eine weitere Entwurfsfreiheit. Ich kann damit Abläufe modellieren.
daten eingabe->verarbeitung->ausgabe ist sequentiell, wenn man die daten eingabe bzw ausgabe in einen anderen thread stellt, der dann eine "virtuelle" dateneingabe für den hauptthread erstellt, sind es keine voneinander unabhängige abläufe, sondern ein ablauf der auf viele threads aufgeteilt wird, die sich sequentiell verhalten und auf singlecores absolut kein performance+ bringen, eher sogar das gegenteil.
edit: oh, falsch gelesen, Dein "wir sind uns nicht einig" steht ja früher im Text... Wir sind uns also nicht einig, daß OOP was Sinnvolles ist. Damit können wir uns das natürlich alles sparen.. mein Argument geht natürlich in die gleiche Richtung der Abstraktion, die auch OOP mit sich bringt. Wenn das für Dich kein Argument ist, dann bei der Sache mit den Threads natürlich auch nicht.
jup, so ist das leider. ich würde kein OOP benutzen, auch wenn es abstrahierter ist, wenn es anderen lösungen gegenüber soviele nachteile hat, dass es nicht sinnvoll ist.
rapso->greets();
