TFile, TDirectory vs. alte Funktionen

[bernau]

Ich habe es nun endlich geschafft. Bin von Delphi 2007 auf XE8 umgestiegen. Man schaut dann natürlich nach neuen Klassen, Datenstrukturen etc.

Beim Stöbern durch das Emba-Wiki habe ich folgende Typen gefunden TFile, TPath, TDirectory. Darunter sind etliche nützliche Klassenmethoden vorhanden. Vieles gibt es natürlich schon in der RTL. Z.B. ersetzt Tfile.exists die Funktion fileexists. Ich finde die neue Schreibweise sehr angenehm. So muss ich nur "TFile." eingeben und die Codevervollständigung gibt mir alle Funktionen, die ich mit Dateien machen kann. Seit wann gibt es diese Typen?

Ich denke ich werde die neue Schreibweise übernehmen. Wie findet Ihr diese Schreibweise?

[Der schöne Günther]

Natürlich nur das. Ist ja nicht nur eine andere (ordentliche) "Schreibweise", sondern viel Neues: Dinge wie TDirectory.GetFiles(..) machen das Leben doch gleich unheimlich viel angenehmer

[Daniel]

Zitat von bernau:

Ich denke ich werde die neue Schreibweise übernehmen. Wie findet Ihr diese Schreibweise?

Die neue Funktionalität möchte ich nicht mehr missen. Zudem empfinde ich ein TDirectory.Exists() als angenehm lesbar und hinreichend selbstbeschreibend.

[Sir Rufo]

Viele von diesen Strukturen sind von .net inspiriert (was es ja nicht schlecht macht)

• TDirectory => Directory
• TFile => File
• TPath => Path

Wenn man sich die .net Struturen allerdings so anschaut, dann fragt man sich, wann das denn kommt, oder ob man das besser selber implementiert.

[alda]

Zitat von Sir Rufo:

Viele von diesen Strukturen sind von .net inspiriert (was es ja nicht schlecht macht)

• TDirectory => Directory
• TFile => File
• TPath => Path

Wenn man sich die .net Struturen allerdings so anschaut, dann fragt man sich, wann das denn kommt, oder ob man das besser selber implementiert.

Ich wollt schon sagen ... letztendlich endet es darin, dass man es selbst richtig macht - sitze ich zufälligerweise gerade auch dran die IOUtils wurden halt wieder von einem unterbezahlten Praktikanten programmiert

[bernau]

Zitat von alda:

Ich wollt schon sagen ... letztendlich endet es darin, dass man es selbst richtig macht - sitze ich zufälligerweise gerade auch dran die IOUtils wurden halt wieder von einem unterbezahlten Praktikanten programmiert

Begründung? Was ist schlecht oder funktioniert nicht?

[alda]

Zitat von bernau:

Zitat von alda:

Ich wollt schon sagen ... letztendlich endet es darin, dass man es selbst richtig macht - sitze ich zufälligerweise gerade auch dran die IOUtils wurden halt wieder von einem unterbezahlten Praktikanten programmiert

Begründung? Was ist schlecht oder funktioniert nicht?

Weil es nicht objektorientiert ist. Drei Records hingeklatscht und paar Klassenmethoden implementiert, fertig ist der Nudelsalat. Gerade beim Dateisystemzugriff wäre es schön wenn es "richtig" (Interfaced) gemacht worden wäre, sodass man das beim Testen wegmocken kann und nicht die komplette Unit überschreiben muss.

[bernau]

Zitat von alda:

Weil es nicht objektorientiert ist. Drei Records hingeklatscht und paar Klassenmethoden implementiert, fertig ist der Nudelsalat. Gerade beim Dateisystemzugriff wäre es schön wenn es "richtig" (Interfaced) gemacht worden wäre, sodass man das beim Testen wegmocken kann und nicht die komplette Unit überschreiben muss.

Muss es objektorientiert sein? Was ist an den Klassenmethoden falsch? Es macht genau das, was es soll. Ein paar Funktionen zusammenfassen, sodaß es "schön" aussieht.

Warum ist "Interfaced" = "richtig"? Warum sollte ich erst etwas instanzieren müssen, wenn es auch so geht.

Aber ich lerne gerne. Gib mal ein Beispiel, wie ein einfaches TFile.exists(aFilePath) bei dir aussieht.

[Sir Rufo]

Es geht hier nicht um das einfache TFile.Exists . Diese Methoden sind im Übrigen in .net analog umgesetzt (mit einer statischen Klasse).

Aber man hat dort eben nicht aufgehört und auch noch so nette Dinge wie DirectoryInfo, DriveInfo, FileInfo dort implementiert, die das Leben einfacher machen.

[alda]

Zitat von bernau:

Zitat von alda:

Weil es nicht objektorientiert ist. Drei Records hingeklatscht und paar Klassenmethoden implementiert, fertig ist der Nudelsalat. Gerade beim Dateisystemzugriff wäre es schön wenn es "richtig" (Interfaced) gemacht worden wäre, sodass man das beim Testen wegmocken kann und nicht die komplette Unit überschreiben muss.

Muss es objektorientiert sein? Was ist an den Klassenmethoden falsch? Es macht genau das, was es soll. Ein paar Funktionen zusammenfassen, sodaß es "schön" aussieht.

Warum ist "Interfaced" = "richtig"? Warum sollte ich erst etwas instanzieren müssen, wenn es auch so geht.

Aber ich lerne gerne. Gib mal ein Beispiel, wie ein einfaches TFile.exists(aFilePath) bei dir aussieht.

Dann haben wir wohl verschiedene Auffassungen von "schön" aussehen In diesem Fall würde ich sagen: Ja das muss objektorientiert sein. Ich hab nichts gegen prozedurale Programmierung, die macht aber eben nur an wenigen Stellen Sinn.

Der Zugriff auf ein Dateisystem ist eigentlich dafür prädestiniert mit Abstraktionen/Schnittstellen zu arbeiten. So hat man dann nicht innerhalb seiner TFile.Exists(path) Methode seine 300 Zeilen Code (übertrieben) mit 40 IFDEFs (auch übetrieben ), sondern eine einheitliche, vollständige und korrekt benannte API für den Entwickler und dahinter die verschiedenen Implementierungen für OSX, Android, Windows, eben abhängig von der Plattform.

Außerdem hast Du mit so statischen vorgehensweisen wie "TFile.Do*(Pfad)" auch immer das Problem, dass Du durch dein Programm hinweg einen String mit Dir rumschleppst, den Du (wenn Du nicht gerade alleine arbeitest) zur Sicherheit vor jeder Verarbeitung überprüfst/auseinander nimmst -> ExtractFileExt, ExtractFilePath, ExtractFileName etc pp. Einfacher wäre auch hier eine IFile Schnittstelle die eine Datei repräsentiert und auf der ich ein IFile.Exists, IFile.FileExt, IFile.Location etc aufrufen kann - nie wieder unnötige String/Pfad Verarbeitungen.

Und wenn ich 1000-5000€ für die IDE/Sprache bezahle, dann erwarte ich auch dass ich für mein Geld was geboten bekomme - das ist zumindest meine Meinung