nicht angemeldet
Hi!
- Problem
Ohne mich genau au die Gegebenheiten zu erinnern, fällt mir da zumindest Debug als Stichwort ein. Ist es nicht so gewesen, dass man einerseits Debug-Meldungen schreiben kann und andererseits einen Listerner braucht, der darauf reagiert und etwas unternimmt?
Andererseits, wenn du einen Rückkanal brauchst, solltest du diesen Rückkanal dem Kommando-Objekt mit übergeben. Da gibt es sicher auch irgendein Pattern mit Namen dafür. Konkret implementiert wäre das ein Delegate oder vielleicht auch ein Event, für das der Aufrufer einen Eventhandler einklinken kann.
Jaaa, sehr gut, das sind schon mal 2 Ansätze, die mich weiterbringen. Die 2. Lösung mit Event bzw. Delegate ist mir soweit klar. Die 1. Lösung noch nicht 100%ig; vor allem ist mir nicht unbedingt klar, wo der Unterschied zu Lösung 2 wäre. In meinen Augen läuft das doch wieder auf eine eventbasierte Lösung hinaus, oder?
Den Status als Funktionsergebnis zurückzugeben geht sicher auch. Aber da ist es vielleicht sinnvoller, das eigentliche Ergebnis der Arbeit zurückzuliefern. Dazu später noch was.
Das Problem hierbei ist, dass die Statusausgaben Bezug auf Zeilen nehmen, ein Kommando aber eine ganze Datei verarbeitet. Der Rückgabewert wäre dann ein möglicherweise aus sehr vielen Zeilen der Form "Zeile i konnte nicht geparst werden, weil ... Zeile i+j konnte nicht geparst werden, weil ..." bestehender String. Das erscheint mir unsauber.
- Problem
In den Aufrufer. Nur der weiß im konkreten Fall, was zu tun ist. Ich würde da keine höhere (Gott-)Instanz implementieren, die für sämtliche Problemfälle aller beteiligten Komponenten eine Lösung kennen soll. Gegebenenfalls muss eine Komponente die eigentliche bei ihr auftretende Exception in eine allgemeinere oder auch spezifischere (KommandoException) kapseln.
Ich bin mir nicht sicher, ob wir uns hier verstehen. Meinst du, ich soll sämtliche catch-Klauseln in der UI unterbringen? Das wäre natürlich insofern praktisch als ich in den Kommandos und im Transformer Exceptions einfach ignorieren kann. Aber irgendwie muss ich dann in beiden UIs jeweils zig verschiedene Exceptions abfangen.
Zu den Reaktionen auf Exceptions ist auch noch zu sagen: Ich wollte ja auch keinen Layer definieren, der für alle Exceptions eine "Lösung" anbietet. Die ist na noch nichtmal unbedingt notwendig. Auf der Kommandozeile würde ich z.B. einfach eine Fehlermeldung rausschreiben, wenn eine Eingabedatei nicht gefunden wurde und das auslösende Kommando ignorieren. Ich wollte einen Layer, der alle Exceptions abfängt und auf einheitliche Art und Weise an die UI weiterreicht; echte Fehlerbehandlung hätte ich da nicht vorgesehen. Insofern ist eine KommandoException o.ä. sicherlich nicht verkehrt; sowas in die Richtung hab ich auch schon implementiert.
Was dieses Problem angeht, bin ich noch nicht wirklich schlauer.
- Problem
Daran könnte nicht stimmen, dass du statt der Daten den Weg zu den Daten angibst und sich das Kommando die notwendigen Zugriffsprozeduren auch noch mit sich rumschleppen muss
Ich glaube, das fasst meine Bedenken ziemlich gut in Worte.
Ich nehme an, "sauberer" ist es, oben Daten einzukippen und unten das Ergebnis abzuholen und Beschaffung und Wegschreiben außerhalb durch Spezialisten erledigen zu lassen. Dann kannst du diese Spezialisten bei Bedarf anpassen oder neue erstellen, ohne die bestehende Funktionalität in den Transform-Klassen zu beeinträchtigen. Zur Not übergibst du halt die fertig initialisierten Spezialisten als Parameter. So bekommst dein Transformationskommando weniger Dinge zu tun, die eigentlich gar nicht zu seinen direkten Aufgaben zählen.
Zwar habe ich noch keine konkrete Vorstellung, wie die Implementierung letztlich aussehen soll, aber das gibt mir schon mal die richtige Richtung vor.
Vor allem auch im Hinblick auf Testbarkeit ist es auf diese Weise besser, weil da nicht irgendwelche Festplattenzugriffe mit getestet werden, sondern Dummys übergeben werden können.
Testbarkeit, richtig, das habe ich ganz vergessen. Man will ja auch für Kommandos, Transformer etc. Unit-Tests schreiben; das macht lose Kooplung nochmal doppelt so wichtig.
Danke
Bernhard