Günther hat geschrieben:
Das mit der Vererbung finde ich nur die zweitbeste Lösung, eine zentrale Klasse finde ich besser (hatte ich ja schonmal in Deinem Thread gepostet), sonst wird der Code nur wieder doppelt und dreifach geschrieben....
uiii, da reden wir vielleicht aneinander vorbei.
grade das Vererben ist doch eine der wesentlichen Stärken von OO (C++), eben damit man
nur den Code schreiben braucht, der die neue bzw. geänderte Funktionalität ausführt !!!
Als denk nochmal drüber nach ...
Ausserdem gibt es noch eine MovieInfo, welche die xml ausliest, spätestens die kannst Du nicht mehr so vererben, das der MB die auch benutzt.
das seh ich aber ganz anders, auch hier muß OO nur richtig zum Einsatz kommen:
1) das Interface von 'CMovieInfo' muß auch entsprechend mit virtuellen Methoden definiert werden.
2) In 'CMovieBrowser' darf man nicht einfach ne Instanz von 'CMovieBrowser' in der Klassendefinition reintun,
sondern muß dort nen Pointer (CMovieInfo *) definieren.
Dann muß noch eine virtuelle Methode z.B. '
CMovieInfo * CMovieBrowser::createMovieInfo()' her,
die standardmäßig ein CMovieInfo Instanz erzeugt, aber in Ableitungen von 'CMovieBrowser' dann
entsprechend überladen werden kann mit einer Ausprägung, die schließlich einen Pointer auf eine
vererbte 'CMovieInfo'-Instanz liefert, die zum jeweiligen Umfeld (z.B. streamer) passt.
Danach kann das "CMovieInfo-Interface" im MovieBrowser Code über diesen Pointer wie gewohnt angesprochen werden
und erreicht auch jeweils die zuvor "transparent" erzeugte Instanz !!!
-> so geht OO ...
3) auch schon mal erwähnt - vielleicht nicht verständlich genug - hab ich, daß die Schnittstellenmethoden von 'CMovieInfo'
(und evtl. auch anderer Klassen) so verwendet (verdrahtet) sein müssen, daß der normale Browser-Ablauf nicht darunter leidet,
wenn keine Daten zurückkommen (evtl. durch boolschen Rückgabewert 'false' kann das signalisiert werden oder so).
Dann können auch Subsysteme (wie streamer) eingebunden werden, die keine bzw. nicht alle "Infos" liefern können.
Einzig als zwingend für jedes Subsystem ist doch nur die Hauptfunktion, nämlich das "Browsen" !
Es gilt immer noch die Weisheit: Wiederverwendbarkeit und Aufwand für Erweiterungen hängen davon ab,
wie das basierende Klassensystem strukturiert ist.
Je besser Schnittstellenfunktionen gewählt und verdrahtet sind je geschickter irgendwelche "Hooks" verfügbar sind,
in die man sich per "Überladen" einhängen kann, um so
einfacher wird es für Folgeentwicklungen.
Leider ist manchmal aber auch der Aufwand zur Entwicklung des Basissystems etwas höher - aber das verhält
sich doch auch nur so wie mit "Investitionen" in der Finanzwelt
Gib doch deinem "Movie-Browser" bitte die Chance eine flexible Basis für die Zukunft zu sein.
Man weiß ja noch nicht, was im Laufe der Zeit so alles damit angestellt werden könnte.
Ich habe die Funktionen readDir_vlc usw. nur in aller Eile für vlc/streamer vorbereitet, damit der MB leichter dort zu integrieren ist.
gut, aber das ist im Prinzip der richtige Ansatz, daß eben das "Füllen" der Directory-Liste als
ein - sagen wir mal - autarker Arbeitschritt gezielt in einer Methode abgefackelt wird.
Damit ist es ein Leichtes, eben nur diese Methode durch Vererbung anzupassen und so mit geringstem Aufwand
ein anderes Subsystem zu integrieren. ->Hab ich doch erfolgreich so mit streamer gemacht !
- GMo -
. In allem von Dir gesagtem stimme ich natürlich 100% zu - naja und es gibt ja immer mehr als eine Lösung, ich lasse mich da auch gerne überzeugen (vielleicht könnte noch ein anderer OO-Spezi seinen Senf dazu abgeben 
)
). Zu der " Anzeige in der Filmbeschreibung. Die kommt von der Umwandlung von UTF8 in das sog. UTF8XML Format, bevor der EPG in das XML geschrieben wird (Wenn Du die Datei mit dem Notepad aufmachst siehst Du das "). Eine Zurückumwandlungsroutine habe ich in Neutrion nicht entdeckt, werde die also selber schreiben müssen (ist nicht wirklich kompliziert, aber muss auch wieder getestet werden)