Datei-Splitter mit strenger Objektorientierung

[scopsen]

Hallo zusammen,

ich muss als ein Projekt einen Datei-Splitter in Delphi programmieren, der eine grosse Datei in viele kleine Dateien zerschneidet (so dass sie z.B. auf eine Diskette passen) und später auch wieder zusammenfügen kann.

So weit kein Problem denke ich!

Allerdings sind die Rahmenbedingungen gegeben, dass ich diese Aufgabe unbedingt mit der Konzeption der Objektorientierten Programmierung lösen muss.

D.h. im speziellen:

• eigen Klassen entwickeln und verwenden
• Vererbung bzw. Wiederverwendung
• Polymorphie
• etc.

Das Problem für mich besteht nun vor allem darin die Klassen in meiner Aufgabenstellung bzw. meinem Programm zu identifizieren um somit ein Klassendiagramm aufzustellen bzw. die Klassen selbst zu implementieren.
Ich denke nicht, dass ich dabei zwingend alle Eigenschaften der Objektorientierung verwenden muss, aber ich kann in diesem minimalen Programmierproblem einfach keine sinnvollen Klassen finden.


Ich hoffe ihr habt einen Lösungsansatz oder konkrete Ideen für mich, damit wir ein wenig darüber diskutieren können.

Ich warte auf eure Antworten.
scopsen

[SirThornberry]

wo liegt das problem?

Delphi-Quellcode:

type
  TSplitter = class(TObject)
  protected

  private

  public
    procedure splitmyfile(Filename: String....);
  end;
[...]
procedure TSplitter.splitmyfile(Filename: String....);
begin
  //datei aufteilen etc
end;
[...]
procedure TForm1.irgendwas;
var splitter: TSplitter;
begin
  splitter := TSplitter.Create;
  splitter.splitmyfile('c:\nedatei.txt',....);
  splitter.Free;
end;

ist doch ziemlich einfach ne klasse zu schreiben in delphi oder hab ich da was falsch verstanden?? Und die methoden die durch vererbung überschrieben werden können sollen einfach in protected rein..

[Edit1]
Wenns unbedingt ne eigne Klasse sein soll dann einfach noch eine Klasse für die Datei usw. Im prinzip für alles mögliche eine eigene Klasse. Denn eigentlich willst du ja die datei splitten, somit müsste das splitten eine methode des Dateiobjectes sein... (voll sinnlos die aufgabe, ist unnötig viel aufwand das ganze in klassen zu packen)
[/Edit1]

[Luckie]

Also ich weiß nicht, ob das bei einem FileSplitter so günstig ist. Im Endeffkt ist es nur eine Funktion:

Delphi-Quellcode:

function SplitFile(Filename, DestFolder: string; SplitSize, CntParts: Cardinal):
  Integer;
const
  BLOCKSIZE = 32767;
resourcestring
  ChangeDiskMsg = 'Legen sie die nächste Diskette in Laufwerk a: ein.';
var
  hFile: Integer;
  SizeOfFile: Cardinal;
  hPart: Integer;
  Loop: Integer;
  Partname: string;
  MemBuffer: array[0..BLOCKSIZE - 1] of Byte;
  BytesToRead, BytesRead, BytesWritten: Integer;
  TotalBytesRead, OverallBytesRead: Int64;
  ProgressCurrent, ProgressOld: Cardinal;
begin
  bRunning := 1;
  OverallBytesRead := 0;
  SizeOfFile := GetFileSize(PChar(Filename));
  hFile := FileOpen(Filename, $0000);
  if hFile <> -1 then
  begin
    for Loop := 1 to CntParts do
    begin
      // Reset variables
      TotalBytesRead := 0;
      ProgressOld := 0;
      BytesToRead := SplitSize * 1024;
      // build filename of the parts
      Partname := DestFolder + '\' + CutPathname(Filename) + Format('.%3.3d',
        [Loop]);
      if FileExists(Partname) then
        DeleteFile(PChar(Partname));
      hPart := FileCreate(Partname);
      if hPart <> -1 then
      begin
        repeat
          BytesRead := FileRead(hFile, MemBuffer, Min(sizeof(MemBuffer),
            BytesToRead));
          BytesWritten := FileWrite(hPart, MemBuffer, BytesRead);
          Dec(BytesToRead, sizeof(MemBuffer));
          // progress stuff ////////////////////////////////////////////////////
          TotalBytesRead := TotalBytesRead + BytesWritten;
          OverallBytesRead := OverallBytesRead + BytesWritten;
          ProgressCurrent := (OverallBytesRead * 100) div SizeOfFile;
          //sleep(150);
          if ProgressCurrent <> ProgressOld then
          begin
            ProgressOld := ProgressCurrent;
            SendMessage(hApp, FSM_PROGRESS, ProgressCurrent,
              Integer(PChar(Partname)));
          end;
          //////////////////////////////////////////////////////////////////////
        until (BytesToRead < 0) or (bRunning = 0);
      end;
      FileClose(hPart);
      if DestFolder = 'a:' then
      begin
        if MessageBox(0, PChar(ChangeDiskMsg), APPNAME, MB_ICONINFORMATION or
          MB_OKCANCEL) = ID_CANCEL then
        begin
          bRunning := 0;
          break;
        end;
      end;
    end;
    FileClose(hFile);
  end;
  SendMessage(hApp, FSM_FINISH, 0, GetLastError());
  result := GetLastError();
end;

Ich wüsste jetzt noch nicht mal, wie man da sinnvoll eine Klasse drumbasteln könnte. Wäre etwas Overkill. Muss es denn ein FileSplitter sein?

[MrSpock]

Hallo scopsen,

zunächst einmal herzlich willkommen im Delphi-PRAXIS Forum.

Das OOD Konzept schlägt vor, abzugrenzende Objekte der realen Umgebung zu identifizieren und als Kandidaten für Klassen anzusehen. Dabei fallen mir schon mal zwei von einander zu unterscheidende Objekte deines Problems auf. Zum einen benutzt du Dateien und zwar für die Eingabe und die Ausgabe. Es können sowohl für die Eingabe als auch für die Ausgabe eine oder mehrere Dateien zum Einsatz kommen, je nachdem ob sie gesplittet oder zusammengestzt werden sollen. Außerdem gibt es da den Splitter, der eine Assoziation zu den Dateien hat, aber auch Attribute, wie die zu erzeugende Dateigröße. Das wäre schon einmal ein Start.

[chris_82]

Erste Klasse: Deine Form über die du wohl die ganzen Eingaben und dergleichen machen wirst.

...aufgrund der Aufgabe denk ich das wir uns sicher morgen über den Weg laufen werden .

[scopsen]

WoW!

Ich bin wirklich geschockt über die schnellen und konstruktiven Antworten auf mein Thema!

Erstmal denke ich, dass ihr fast einstimmig meiner Meinung seit, dass OOP hierfür ein wenig Overkill ist. Ich dachte anfänglich ich habe das Konzept nicht richtig verstanden bzw. denke ich kann ich immernoch nicht wirklich objektorientiert denken.

Soweit danke für die Ansätze. Ich warte gerne noch auf andere Ideen und Meinungen.
Erstmal muss ich jedoch selber angestrengt über die Postings und die Problematik nachdenken

@SirThornberry:
Ja, ich denke auch, dass es in Delphi nicht so schwer ist eine Klasse zuschreiben. An dem Syntax scheitere ich nicht, den hab ich mir mehr oder weniger schon angeeignet. Allerdings hab ich noch keine komplette Klasse selber geschrieben.
Ich muss erstmal welche finden...

@Luckie:
Danke für die Funktion!
Vielleicht kann ich etwas (bzw. ein paar Ansätze für das eigentliche Programmierproblem) daraus ableiten, sofern ich sie dann mal nachvollzogen und verstanden habe. Scheint für mich auf den ersten Blick doch sehr kompliziert. Aber das schaff ich noch..!
P.S.: Leider hab ich bei der Auswahl der Aufgabe nicht vermutet, dass die OO bei diesem kleinen Progrämmchen Probleme macht.

@MrSpock:
Das hört sich sehr interessant an und scheint mir sehr einleuchtend. Ich werde das so mal weiterverfolgen und dann in den nächsten Tagen, hoffe ich, meine Fortschritte hier dokumentieren.

@chris_82:
Wir sehen uns morgen!

Nochmal Vielen Dank an alle!
scopsen

[Chewie]

Ich finde nicht, dass das OOP-Konzept für diese Aufgabe oversized ist. Eine Klasse muss ja nicht gleich die ganze Welt beschreiben, eine sinnvolle Klasse kann genausogut nur über ein oder zwei public-Methoden und einige Properties besitzen. Luckies Funktion beispielweise könnte man auch der Übersichtlichkeit wegen (Länge der Funktion nur Bildschirmhöhe) in mehrere private Unterprozeduren zerlegen, die dann in einer als public deklarierten Funktion, der eigentlichen Split-Funktion, aufruft. Die Parameter können über Felder geregelt werden.

Ich finde, man sollte von dem Gedanken wegkommen, Klassen lohnen sich nur bei umfangreichen Projekten.