Wie wäre es denn mit Interfaces?
Mit so einer Antwort habe ich gerechnet
. Der Gedanke kam mir auch schon, und das wäre vermutlich aus Perspektive der Objekt-Orientierung die sauberste Lösung. Dann müsste ich mich während des Auslesens der Metadaten aus einer Datei
vor Erstellung des jeweiligen TTagItems entscheiden, welche konkrete Klasse ich da instanziieren will/muss. Dann ist schon bei der Erstellung definiert, was das Objekt "kann".
Mit Interfaces und Supports() kann ich dann bei der Anwendung direkt eine ganze Reihe in der "2D-Klassen-Matrix" abfrühstücken, und muss nicht jede einzelne Klasse testen. Das wäre auf jeden Fall ein Fortschritt zur aktuellen (nicht-)Lösung.
In meinem ersten Gedanken (Überprüfung in GetText bzw. SetText) wird diese Entscheidung erst später getroffen, indem die TagItem-Klasse checkt, ob es
sinnvoll ist, diese oder jene geerbte Methode auszuführen.
Ob Interfaces für meine Anwendungsfälle ideal wären, muss ich mir nochmal durch den Kopf gehen lassen.
Eine Methode "GetText" ist nämlich manchmal auch für binäre Daten reizvoll (nicht druckbare Zeichen dann durch "." oder so ersetzt, wie bei Hex-Editoren auch). Und bei den "erweiterten Text-Items" müsste ich mir auch noch überlegen, ob ich dafür das Interface "GetText" bereitstelle, oder nicht. (
Lyrics enthalten z.B. im ID3v2Tag nicht nur den eigentlichen Liedtext, sondern z.B. auch noch ein Feld für die Sprache. Da enthält quasi ein TTagItem selbst wieder Metadaten 
)
Mit meiner zuerst angedachten Lösung könnte ich das Verhalten vom Anwender der Library über einen zusätzlichen Parameter "TextMode" steuern lassen, der z.B. "strict", "reasonable" oder "forced" sein kann. Im letzteren Fall (forced) könnte der Anwender dann Unsinn machen (zumindest mit SetText), wenn er will (oder genau weiß, was er tut).
@hanvas: von genau diesen (vielen) Fallunterscheidungen im eigentlichen Programmcode möchte ich ja weg. Ich möchte quasi etwas mehr Programmlogik vom Anwendungscode in die Library verschieben. Aktuell ist das noch wirrer, da die "GetAllTagItems"-Methode in jeder Tag-Klasse anders heißt, und auch nicht immer den gleichen Listentyp haben will (TObjectList, TList, TStringList).
Aber danke für die Anregungen - das hilft ja oft schon, um sich selbst besser klar zu werden, was man eigentlich will.
