Also, dann mal ganz langsam:
-
Factory
ist ein Objekt, das Methoden zur Verfügung stellt, über die man alle möglichen anderen Arten von Objekten erzeugen kann. - In diesem Fall wollen wir über die Funktion
CreateMetadataHandler
ein Objekt vom TypIMetadataHandler
erzeugen, mit dem wir die Tags auslesen können. - Die Funktion
CreateMetadataHandler
bekommt dabei als Parameter das PlaylistItem übergeben, auf dem der Handler arbeiten soll - damit der direkt weiß, mit welcher Datei und welchem Item er es zu tun hat. - Dann wird dessen Methode
ReadNativeTags
aufgerufen, um die ID3-Tags zu lesen und in den PlaylistItem-Datensatz zu kopieren.
“Unabgekürzt” (und besser zu verstehen) würde das so aussehen:
item := CurrentPlaylist.GetItem(i);
handler := Factory.CreateMetadataHandler(item);
handler.ReadNativeTags;
Durch die Kurzschreibweise ersparen wir uns die ganzen Variablendeklarationen.
Du siehst, die Interna von mAirList sind manchmal sehr kompliziert. Aber bieten doch eine Menge Funktionalität. Die Script-Engine ist euer Guckloch in diese Welt.
Um die Sache etwas intuitiver zu machen, könnte ich dem IPlaylistItem
eine Methode CreateMetadataHandler
geben, die nur eine Abkürzung für Factory.CreateMetadataHandler(item)
ist. Dann würde es so aussehen:
CurrentPlaylist.GetItem(i).CreateMetadataHandler.ReadNativeTags;
Wäre das besser zu verstehen?
Übrigens, bei den Typen mit “I” vorne (IPlaylistItem
, IMetadataHandler
, …) handelt es sich allesamt um “Interfaces”, also “indirekte” Verweise auf Objekte. Die dann wiederum Methoden haben, die man aufrufen kann.
Die Verwendung von Interfaces statt normaler Objektreferenzen erlaubt es in Delphi, dass man “reference counting” macht. Also Objekte, die sich selbst aus dem Speicher löschen, sobald niemand mehr auf sie zugreift. Daher der Umweg über Interfaces. Beim Programmieren immer die doppelte Arbeit, da man sowohl das Interface als auch das implementierende Objekt definieren muss. Aber am Ende hat es nur Vorteile.