Klassen Wie mache ich das "the java way"?

br0nko

Mitglied
Wertes Forum,

nachdem ich nun einige Zeit mit der Einarbeitung verbracht habe und glaube die Grundlagen von Java soweit erstmal halbwegs begriffen zu haben, hab ich eine konzeptionelle Frage. Dazu kurz ein Umriss von dem was ich bisher geschafft habe: Ich programmiere gerade ein kleines tool, welches Midi Daten von einem externen Midi controller abgreift, diese visualisiert und auch ein bisschen Midi output macht. Das klappt alles ganz prima, genau nach meinem Geschmack. Angefangen hatte es ganz furchtbar mit einem dutzend singleton classes, da ich mit dem Kopf noch zu sehr in der prozeduralen Welt hängen geblieben war. Mittlerweile habe ich das ganze brav in Klassen verpackt und glaube zumindest diesen Teil von OO zu verstehen.

Die Klasse kümmert sich um das sensing der hardware, holt aus dem java MidiSystem einen Receiver und einen Transmitter und schon geht's los. Ich empfange Midi Daten in der Klasse und kann diese auf der Konsole ausgeben.

Eine Instanz der Klasse rufe ich aus main auf:

Code:
MyDeviceClass device = new MyDeviceClass();

Im Konstruktor der Klasse wird dann eine interne listen() Methode aufgerufen, die auf den input stream wartet.

Sorry, ganz schön lange Einleitung. Hier meine Frage:

Wie mache ich nun weiter? ???:L Mein Plan ist verschiedene Ereignisse aufgrund von bestimmten Midisignalen auszulösen. Wie leite ich am elegantesten die Daten aus der MyDeviceClass raus um sie anderswo auszuwerten und abhängig von bestimmten Parametern Aktionen zu triggern? Baue ich eine extra "routing" Klasse, die Aufrufe entgegennimmt und weiterleitet? Sollte es lieber sowas wie eventListener geben, die immer am lauschen sind? Baue ich einfach eine handvoll singletons?
Da mein Ziel ist, die Daten in Abhängigkeit von bestimmten Parametern an ständig unterschiedliche Orte zu leiten, tendiere ich zu der routing Methode, quasi eine Klasse, die jedes Signal annimmt und dann entscheidet wo es hin soll. Nur wie soll dieses "hin" überhaupt implementiert sein? Auch eine Klasse? Singletons?

Ihr seht schon, da hakt bei mir ein bisschen das Verständnis für OOP.. vielleicht könnt Ihr mir ja einen Schubs in die richtige Richtung geben. Hoffe ich konnte verständlich machen, was ich meine. Gar nicht so einfach so eine abstrakte Frage in Worte zu giessen 🙂 Wenn es gar nicht verständlich ist versuche ich nochmal nachzulegen 🙂

Danke & Grüße
 
Schwer zu sagen, auf basis der Beschreibung.

Singletons werden "meistens" falsch verwendet, aber bei so etwas 1:1 an Hardware gekettetem wie einem Midi-Listener könnte ein Singleton sogar angebracht sein. Die entscheidende Frage ist: DARF es IMMER nur GENAU EINE Instanz dieser Klasse geben? Wenn ja, sollte sie ein Singleton sein.

Aber für die "verarbeitenden" Klassen gilt das dann schon nicht mehr. So, wie es bisher klang sollten die in jedem Fall passiv sein. Ganz subjektiv-unfundiert: Ein Konzept bestehend aus Listenern und Events wäre vermutlich angebracht, wenn es "(einzelne) spontan auftretende Ereignisse" gäbe, die an potentiell viele Beobachter weitergemeldet werden sollen. Bei sowas wie Audio- oder Video-Processing gibt es aber auch oft das Konzept von "Sinks", also Datensenken, die einen "Strom" von Daten erhalten können... Was für MIDI mehr passt, weiß ich spontan aber auch nicht... :bahnhof:
 
Die entscheidende Frage ist: DARF es IMMER nur GENAU EINE Instanz dieser Klasse geben? Wenn ja, sollte sie ein Singleton sein.

Ich bin nicht böse wenn jemand ein Zweitgerät gleicher Bauart an meinen Rechner anschliesst. Da das MidiSystem mir für diese hardware unbegrenzt Receiver und Transmitter zur Verfügung stellt halte ich es für Sinnvoll, das als Klasse bestehen zu lassen. Insofern bin ich mit der device Klasse auch durchaus zufrieden. Die funktioniert bestens und macht genau das was ich will. Meine Frage zielt eher auf das "danach" ab.

Vielleicht noch etwas konkreter: Die device Klasse enthält die listener() Methode, welche automatisch beim erstellen einer Instanz lauscht. Die Signale die Reinkommen sollen an (bisher) fünf verschiedene virtuelle "modes" geschickt werden. Jeder dieser modes ist den anderen zwar ähnlich, jedoch gibt es auch diverse grundlegende Unterschiede. Wie ich diese "modes" implementieren soll weiss ich nur nicht. Die sollen sich gegenseitig nämlich auch "an und aus" schalten können. So, dass immer nur einer zur Zeit aktiv ist. :bahnhof:
 
Einen ModeManager wäre meien idee dazu

Enumeration mit allen modes,
activateMode im Modemanger mit enumeration als paramter ruft im derzeit aktiven dann deaktivate auf, und im neuen aktivate.
Mode ist also ein Interface, dass dann alle deine Modes implementieren.
Beim Starten würde ich alle Modes erstellen und im ModeManager ablegen (zb Hashmap<ModeEnumration,Class implementing Mode)
worüber du dann die Modes erreichen kannst ohne jedesmal neu zu erstellen(und evtl wichtiger die die alten werte behalten vom letzten mal als sie aktive waren).
 
Einen ModeManager wäre meien idee dazu

War auch mein erster Gedanke dazu. Hatte allerdings die Befürchtung, dass das nicht gerade dem Java Konzept entspricht. Aber mit den Interfaces (ohne jetzt vollständig durchdrungen zu haben wie sie funktionieren) scheint das ein praktikabler Ansatz zu sein. Danke! :toll:

Wenn noch jemand weitere Ideen hat, immer her damit. So lange lese ich mal das Kapitel über interfaces 😉

Gruß, bronko
 

Neue Themen


Zurück
Oben