TIniFiles in eigener Klasse benutzen

[Gambit]

Moin,

ich wollte mir mal angewöhnen in meinen zukünftigen Delphi-Projekten etwas mehr OOP-mäßig vorzugehen...

Ich entwickle jetzt gerade ein Projekt, in dem ich auch eine .ini-Datei benötige. Jetzt habe ich mal versucht eine Klasse zu schreiben, mit der ich bisher nur den Pfad der .ini Datei setzen und auslesen kann:

Delphi-Quellcode:

unit IniUtils;

interface

type
  TIni = class(TObject)
    procedure SetIniPath(aPath: String);
    function getIniPath: String;
private
  IniPath: String;
end;

implementation

procedure TIni.setIniPath(aPath: String);
begin
  IniPath:= aPath;
end;

function TIni.getIniPath: String;
begin
  result:= IniPath;
end;

end.

Jetzt habe ich mir gedacht, dass es vielleicht sinnvoll ist, hier auch Methoden reinzupacken, die die einzelnen .ini Sektionen setzen und einlesen können. Dazu bräuchte ich ja dann wiederum Methoden aus TIniFiles. Würde es dann reichen TIniFiles einmal zu instanziieren? Könnte ich das im Construktor meiner Klasse machen? Dazu müsste ich dann wohl den Construktor überschreiben, oder?
Oder ist es besser, meine Klasse gleich von TIniFiles abzuleiten?

Gruß

Gambit

[Jelly]

Hallo,

schön, daß du OOP lernen willst. Ist immer zu begrüßen.

Jetzt mal zu deiner Klasse. So, wie du sie definierst, bringen dir die Setinipath und getinipath nichts, wenn du nicht auch eine Eigenschaft (stichwort property) unter public deklarierst, damit du auch von aussen drauf zugreifen kannst.

Zu deiner Frage. Klar, wenn du in deiner neuen Klasse spezielle inifile-Funktionen ergänzen willst, brauchst du auf jedenfall eine Instanz auf eine TIniFile Klasse. Deklarier dir dazu eine private Variable, z.B.

Delphi-Quellcode:

private
  ini : TIniFile ;

und reservier Speicher, genau wie du geschrieben hast, im Constructor deiner Klasse. Vergiss dann nicht, den Speicher wieder im Destructor freizugeben.

Gruß,
Tom

[himitsu]

Da er ja eh nichts von TObject verwendet, sollte es doch reichen, wenn er statt TObject TIniile verwendet?

[MLurie]

Grüss Dich

Also.. OOP macht nur Sinn, wenn Du von der Vererbung profitieren willst. Das bedeutet: Deine neue Klasse beruht auf einer bestehenden, in diesem Fall TIniFiles.

Geh über neue Komponente, wähl TIniFile als Basis-Klasse und gib nen neuen Namen für Deine Klasse ein. Mit Stichworten wie inherited kannst Du alle Fähigkeiten von TIniFile verwenden ohne diese neu schreiben zu müssen (Vererbung). Du schreibst lediglich jene Teile neu, welche anderst ausgeführt werden sollen (Override).

Wenn Du lediglich bestehende Funktionen von TIniFiles verwenden willst, dann brauchst kein OOP, sondern eine Instanzierung während der Laufzeit:

var
IniFile: TINiFile;

begin
IniFile:=TIniFiles.Create(PfadzumFile);

Jetzt kannst mit IniFile.ReadString Werte auslesen. (Zu den Befehlen siehe OnLine-Hilfe TIniFiles.

Viel Spass, nicht durchhängen..
Michael

[Gambit]

Danke für die Antwort!
Könntest du mir das mit der Property im Publicteil noch mal genauer erklären? Kann ich denn meine beiden Methoden so beibehalten oder wie müsste ich die abändern?

Und diese Sache mit dem Constructor? Ich leite doch im Moment meine Klasse vo TObjects ab. Wie könnte denn so ein Con/Destructor aussehen, wenn ich TIniFiles mit einbinden will?

Gruß

Gambit

[MLurie]

Rehi

Also, wie gesagt - es macht keinen Sinn eine Klasse zuerstellen, wenn die Funktionen bereits vorhanden sind. Klassen machen nur Sinn, wenn Du sie erweiterst. Da Du nur Grundfunktionen verwendest, brauchst Du keine Klasse und damit ist der Code zwar lehrreich, aber unnötig.

Wenn Du die IniFile-Klasse erweitern willst, dann schau in der OnLine-Doku nach, wie man eine neue Klasse erstellt. Grundsätzlich so, wie beschrieben. Aber versuch Dich an einem einfacheren Beispiel wie ein TButton mit wechselnder Farbe bei Click.

Greifst Du allerdings aus Deinem Programm auf die IniFile-Klasse zu, dann brauchst Du nur, wie angegeben die IniFiles-Create-Methode auszuführen. Dadurch entsteht eine Instanz und beim Aufruf führt Create automatisch den constructor der Klasse aus.

OOP bedeutet nicht, dass alles in ne Klasse rein muss, sondern das Klassen (Objekte) verwendung finen. Wenn Du TIniFiles benutzt, dann programmiest Du OOP, weil Du eine Klasse instanzierst und diese verwendest. Das neuschreiben von Klassen ist nur in wenigen Fällen notwendig: Wenn es keine Komponete für den Zweck gibt oder Du von Vererbung gebrauch machst.

Wenn Du ein korrektes Gerüst für Deine Klasse brauchst, dann erstell sie via Menu (Neu - Komponente).

Der Code, wie Du angegeben hast, scheint mir nicht viel Sinn zu machen. Das zuweisen via SetIniPath usw. geht einfacher mit einem published-Abschnitt

Published
IniPath: String; Read FIniPath Write FIniPath

Ich fürchte eine genaue Ausführung sprengt den Rahmen dieses Boards. Ich empfehle in solchen Fällen einen Gang in die Bücherei oder eben die Doku.

Michael

[Gambit]

OK, jetzt mal ganz ohne TIniFiles und mal zurück zu meiner Klasse.
Wenn ich eine Form(Form1) erstelle und dort diese Klasse benutze, funzt es aber zunächst. Im OnCreate Ereignis von Form1 setze ich, nachdem ich mit ini:=TIni.create das Object instanziert habe, mit SetIniPath('Pfad') den Pfad und kann ihn, dort wo ich ihn benötige auch mit GetIniPath abrufen. Was ist denn daran jetzt so falsch?
Wenn ich allerdings eine zweite Form(Form2) erstelle und den Pfad dort über Form1.ini.GetIniPath abrufen will, klappt das in einer Methode. Will ich es in einer zweiten Methode von Form2 benutzen kachelt das Ganze mit einer Schutzverletzung ab.
Hoffe, das war jetzt so verständlich.
Wie müsste denn meine Klasse richtig aussehen?

Gruß

Gambit

[woki]

Anmerkung:

Funktionalitäten sinnvoll in Klassen verpacken macht immer Sinn, je nachdem was man will sowohl in der Form:

Delphi-Quellcode:

  TMyIniFileManager = Class(TObject)
    ....
    property IniFile: TInifile ...
    ....
  end;

Als auch

Delphi-Quellcode:

  TMyIniFile = Class(TIniFile)
  ....
  end;

Vererbung ist ein wichtiges, aber nicht das einzige Merkmal objektorientierter Softwareentwicklung.

Grüsse
Woki

[Gambit]

Ich möchte eigentlich nur mal gerne wissen, wie meine Klasse aussehen müsste, damit ich mit getIniPath von überall her drauf zugreifen kann nachdem ich ihn zuvor mit setIniPath einmal gesetzt habe. Zum beispiel so:

Delphi-Quellcode:

IniFile:= TIniFile.create(ini.GetIniPath);
  try
    Path:= IniFile.ReadString('DB_Dir', 'Dir','');
  finally
    IniFile.Free;
  end;

Gruß

Gambit

[Luckie]

Kuck dir dazu am besten mal mein Klassen-Tutorial von meiner Seite an. Das sollte erstmal alle deine Fragen klären.