bestehendes Interface an Datastream rankommen

melmager

Erfahrenes Mitglied
ich widerhole mich gerne aber ich habe in Java nicht wirklich den durchblick :-(

eigendlich gehts immer noch um das: (aber nur am Rande)
http://www.tutorials.de/java/380952-java-sound-midi.html

gut ich habe also eine Classe mit einem Interface Transmitter - da kommen daten her
dann gibts eine andre Classe da gibts das gegenstück auch ein Interface Receiver

nun gibts ja auch noch bei Java.IO
DataInputStream und DataOutputStream

kann ich ein bestehendes Interface erweitern um an den Datenstrom der da irgenwo fliesst ranzukommen ?
wenn ja dann könnte ich ja doch meine unerwüschten Daten rausfiltern
 
Zunächst mal wäre es wichtig zu klären was genau du mit Interface meinst.
Meinst du den Klassen-Typ Interface ?
Oder meinst du eine bestimmte Hardware *z.B. NIC = Network Interface Card* ?
Oder bezeichnest du mit Interface lediglich eine Software welche *analog zu einem Hardware-Interface* Daten von einem Medium in ein anderes Umsetzt ?

Wenn du so direkt fragst , ob es möglich ist ein Interface *im Sinne von Klassen-Typ* zu erweitern : JA
Ist es möglich damit die Implementierung zu verändern : JAIN ... du kannst zwar der Implementierung vorgeben welche Methoden zu implementieren sind ... wenn diese aber keinen Inhalt haben ändert es rein logisch nichts an der alten Implementierung.

Hier sind also noch weitere Infos nötig ... vor allem deine Definition des Wortes Interface ... und auch wenn möglich den Source der geannten Klassen.
 
nun gibts ja auch noch bei Java.IO
DataInputStream und DataOutputStream

kann ich ein bestehendes Interface erweitern um an den Datenstrom der da irgenwo fliesst ranzukommen ?
wenn ja dann könnte ich ja doch meine unerwüschten Daten rausfiltern

Wenn Du das folgende Buch in der HTML-Version installierst Handbuch der Java Programmierung findest Du im Kapitel 19 ausführliche Erläuterungen zu Datenströmen und Filtern.
 
Mal davon abgesehen das dieses Werk veraltet ist *letzte Aktulisierung 2007* , nicht wirklich Informativ ist *dein Kapitel 19 ist wirklich sehr dürftig ... da findet man in der JavaInsel deutlich mehr* und auch nicht gerade ansprechend aussieht ... sollte man das Entpacken eines ZIP-Files nicht mit Installieren gleichsetzen.

Allgemein trägt dein Post hier eher weniger zur Lösung bei als du denkst ... denn TO wollte wissen wie er ein "Interface" *in welchem Sinne auch immer* durch Ableitung so verändern kann das dierekte Eingriffe in die Funktionsweise möglich werden. Ob das überhaupt möglich ist wird wenn dann nur aus dem Source des "Interfaces" ersichtlich. Wie man dann weiter mit den Streams arbeitet *es wurde hier deutlich erwähnt : Data*Stream ... welche meines erachtens NICHT zu den Low-Level Byte*Stream gehören* steht im Moment weder zur Debatta noch war das bis jetzt gefragt.

*Ich liebe es das jemanden an den Kopf zu werfen : dein Post hat das Thema VERFEHLT*
 
Mal davon abgesehen das dieses Werk veraltet ist *letzte Aktulisierung 2007* , nicht wirklich Informativ ist *dein Kapitel 19 ist wirklich sehr dürftig ... da findet man in der JavaInsel deutlich mehr* und auch nicht gerade ansprechend aussieht ... sollte man das Entpacken eines ZIP-Files nicht mit Installieren gleichsetzen.

Sei bitte genauer wenn Du etwas kritisierst: Was hat seit 2007 am JDK/SDK an den im Kapitel 19 behandelten Klassen konkret geändert?

Allgemein trägt dein Post hier eher weniger zur Lösung bei als du denkst

Woher willst Du wissen, was ich denke! Immerhin kann der TO im Kapitel 19 entnehmen, welche Klassen welches Interfaces implementieren. Im Übrigen gibt es eine aktualisierte 6. Auflage, siehe hier

nun gibts ja auch noch bei Java.IO
DataInputStream und DataOutputStream

kann ich ein bestehendes Interface erweitern um an den Datenstrom der da irgenwo fliesst ranzukommen ?
wenn ja dann könnte ich ja doch meine unerwüschten Daten rausfiltern

Im Kapitel 19 meines Links wird folgendes gesagt:

Die Aufgabe der aus FilterInputStream abgeleiteten Klassen besteht darin, die Lesezugriffe abzufangen, in einer für sie charakteristischen Weise zu verarbeiten und die Daten erst dann an den Aufrufer weiterzugeben.

Du könntest nun eine eigene Klasse erzeugen, welches die Klasse FilterInputStream erweitert und im Konstruktor dein verwedetes DataInputStream als Argument bekommt. Im Konstuktor muss man das Argument mit super() der erweiterten Klasse übergeben. Je nachdem was Du filtern willst, kann der Konstruktor weitere Argumente annehmen. Innerhalb dieser Klasse musst Du die read() Methode gemäss Deinem Filter überschreiben.

Der Aufruf instantiiert diese Klasse und übergibt den DataInputStream an die Filterklasse. Nun werden alle reads() über den überschriebenen read() geleitet und wie gewünscht gefiltert.
 
Zuletzt bearbeitet:
Also ich meine ein interface in java.
und zwar das :
javax.sound.midi
Interface Transmitter
und nein es ist kein File - wenn ich mit java.io ein file öffne ist mir ja klar wo der stream ist -
ein filestrem gibts bei MIDI leider nicht

und da ich nicht weiss wo ich den Quellcode herbekommen soll fällt die analyse auch aus ...

also doch projekt beerdigen
 
Achso ... dann sag das doch gleich das du immer noch an deinem MIDI-Projekt sitzt und das du eine Interface-Klasse meinst ... dann hätte man dir viel schneller eine Antwort geben können :

Es bringt dir nichts wenn du ein eigenes Interface von javax.sound.midi.Transmitter ableitest ohne eine konkrete Implementierung. Du müsstest wenn also eine Klasse haben die eine konkrete Implementierung des Interfaces ist und von dieser ableiten. Und ob du es dann schaffst an die gewünschten Informationen zu kommen ist auch fraglich.

Um also auf deine Frage dierekt zu antworten : NEIN ! Du könntest allerhöchstens was mit der konkreten Implementierung anfangen.
 
@j2se
Weil es KEIN Midi-File gibt wenn du z.B. den Input von einem Midi-Keyboard lesen willst ... worum es ja im Endeffekt immer noch drum geht.

Das Problem war wohl soweit wie ich es mitbekommen habe das das Keyboard auch Daten sendet wenn man nichts macht ... also eine Art keep-alive Paket nach dem Motto : Hallo , ich bin noch da ...
Und was TO jetzt wollte war halt über das Sound-System an den InputStream kommen um eben diese keep-alive Pakete zu filtern ... was aber nur durch Erweiterung des Interfaces selbst nicht möglich ist ... sondern höchstens wenn man die Implementierung des Interface anzapft oder verändert.
 
@j2se

Das Problem war wohl soweit wie ich es mitbekommen habe das das Keyboard auch Daten sendet wenn man nichts macht ... also eine Art keep-alive Paket nach dem Motto : Hallo , ich bin noch da ...
Und was TO jetzt wollte war halt über das Sound-System an den InputStream kommen um eben diese keep-alive Pakete zu filtern ... was aber nur durch Erweiterung des Interfaces selbst nicht möglich ist ... sondern höchstens wenn man die Implementierung des Interface anzapft oder verändert.

genauso sieht es aus das Keyboard sendet immer Daten ob Taste gedrückt wurde oder nicht und leider vermurksen diese Daten die einfach nur sagen - ich bin noch da - meine gewollten Daten wie es wurde Taste C gedrückt

Also Java kann MIDI Daten rausgeben aber einlesen von externer Quelle geht einfach nicht
 
Zurück