Lose Funktionen in Klassen kapseln?

[Pseudemys Nelsoni]

Moin,

ich habe ne menge lose funktionen in einer meiner unit die ca so aussehen;

AddTok()
GetTok()
NumTok()

usw... also alles token funktionen....

Ich hab eigentlich bis jetzt keine Probleme damit gehabt, habe aber schon oft von Leuten(hi Robert_G :)) hier im Forum gehört das es besser(?) wäre diese in eine eigene Klasse zu packen.
Was wäre der Vorteil? Mal abgesehen davon das die Namen der Funktionen noch frei sind...

Ich sehe darin eigentlich nur einen Nachteil, nämlich, das man den Kram erzeigen muss(Create) und wieder freigeben...

Also, kurze Frage: Lose lassen oder in Klasse packen?

[alcaeus]

Hallo Pseudemys Nelsoni,

es ist Geschmacksache. Du kannst die Funktionen auch ueber die Unit ansprechen (z.B. TokenizeUn.AddTok() anstatt AddTok() schreiben), um Verwechslungen zu vermeiden. Auf der anderen Seite kannst du aber auch eine Klasse erstellen und anschliessend immer mit dem Objekt arbeiten.
Wie gesagt, es ist in so einem Fall wirklich Geschmacksache. Eventuell liest du dir auch mal dieses Thema durch, die Materie ist irgendwie dieselbe.

@All: ich bitte euch sachlich zu bleiben. Kommentare wie "verwende OOP weils besser" ist, oder "lass es so, OOP ist Schwachsinn" sind ueberhaupt nicht sinnvoll und haben hier nichts zu suchen. Danke.

Greetz
alcaeus

[Pseudemys Nelsoni]

Moin alceaus,

Genau, man kann ja die Unit voranstellen, deswegen versteh ich auch nicht wieso man das in Klassen packen sollte ;). Wenn es deswegen kein OOP sein soll, dann ist kein Programm OOP, denn die funktionen der VCL sind ja alle lose, oder?

[alcaeus]

Hallo Pseudemys Nelsoni,

Zitat:

Zitat von Pseudemys Nelsoni

Genau, man kann ja die Unit voranstellen, deswegen versteh ich auch nicht wieso man das in Klassen packen sollte ;). Wenn es deswegen kein OOP sein soll, dann ist kein Programm OOP, denn die funktionen der VCL sind ja alle lose, oder?

der Vorteil der Klasse ist in diesem Fall, dass du deine Funktionen an das jeweilige Objekt gebunden hast. Ich mach mal ein Beispiel fuer etwas ohne OOP:

Delphi-Quellcode:

type
  TToken = record;
    //....
  end;
function AddTok(...): ...;
function RemoveTok(...): ...;

//.....

var
  Tok1, Tok2: TToken;

//.....

AddTok(Tok1, ...);
AddTok(Tok2, ...);

Eigentlich ist nichts an dem Prinzip falsch.

Delphi-Quellcode:

type
  TToken = class(TObject)
    public
      function AddTok(...): ...;
      function RemoveTok(...): ...;
  end;

//.....

var
  Tok1, Tok2: TToken;

//.....

Tok1 := TToken.Create;
Tok2 := TToken.Create;
Tok1.AddTok(...);
Tok2.AddTok(...);

Ich hab jetzt mal die Konstruktoren weggelassen. Der Vorteil ist dass die Funktionen genau auf das eine Objekt gebunden sind, auch wenn intern nur die Referenz uebergeben wird dass du mit Self arbeiten kannst ;)

Zur VCL: das meisste ist (mehr oder weniger schoene) OOP, aber es gibt auch Ausnahmen.

Greetz
alcaeus

[DGL-luke]

was müsste in den konstruktoren denn drinstehen?

[alcaeus]

Hallo Lukas,

Zitat:

Zitat von DGL-luke

was müsste in den konstruktoren denn drinstehen?

im Constructor kann man z.B. Anfangswerte setzen, eventuelle Unterobjekte erstellen usw. Das kommt ganz auf die Klasse an. Nachdem meine Klasse nur Methoden und keine Properties hat (weil es eine Beispielklasse ist ;)), sind in diesem Fall auch nicht wirklich Initialisierungen wichtig. Ohne properties wuerde die Klasse aber auch keinen Sinn machen.
Wie gesagt, in meinen Augen liegt der Vorteil darin, dass man alles gesammelt hat: Methoden und Properties. Ich denke dass Mario zur Zeit mit records arbeitet, welche die properties des Tokenizers beinhalten, und die Methoden ausserhalb hat. In einer Klasse waere alles schoen gesammelt, aber wie gesagt, es ist Geschmacksache ;)

Greetz
alcaeus

[shmia]

Es ist kein Problem, "normale" Funktion/Prozeduren ist einer Klasse unterzubringen.
Wichtig ist nur, dass die Methoden als Klassenmethoden angelegt werden.

Delphi-Quellcode:

type 
  TToken = class(TObject) 
    public 
      // man beachte das Keyword "class"
      // in anderen Programmiersprachen würde man "static" schreiben
      class function AddTok(...): ...; 
      class function RemoveTok(...): ...; 
  end;

Klassenmethoden kann man aufrufen ohne zuvor ein Objekt erzeugt zu haben:

Delphi-Quellcode:

   TToken.AddTok();

Man braucht auch den Konstruktor oder Destruktor nicht überschreiben, weil es keine Daten im Objekt gibt.

Im .NET Framework ist IMHO alles in Klassen gekapselt.
Ob man "normale" Funktionen/Prozeduren in Klassenmethoden umwandelt ist Geschmackssache;
bei der Performance und Speicherverbrauch gibt es keinen Unterschied.
Vorteil: man sieht sofort am Klassennamen vorhin die Methode gehört
Nachteil: mehr Schreibarbeit

[DGL-luke]

in diesen static funktionen kann man dann aber kein self verwenden, oder?

[shmia]

Zitat:

Zitat von DGL-luke

in diesen static funktionen kann man dann aber kein self verwenden, oder?

Der Compiler erlaubt es nicht, da es den versteckten Self-Parameter in Klassenmethoden nicht gibt.

[Robert_G]

Zitat:

Zitat von DGL-luke

in diesen static funktionen kann man dann aber kein self verwenden, oder?

Wie denn auch, sie werden ja auf den Typ, nicht auf die Instanz angewendet. ;)
Kommt mir das nur so vor, oder wäre nicht bei dem hier...

Delphi-Quellcode:

type
  TToken = class(TObject)
    public
      // man beachte das Keyword "class"
      // in anderen Programmiersprachen würde man "static" schreiben
      class function AddTok(...): ...;
      class function RemoveTok(...): ...;
  end;

...eine Liste von Tokens ganz nett? :gruebel.
Die bekommt Add(aToken :TToken), Remove(aToken :TToken) plus weitere "Nettigkeiten" und alle sind zufrieden und befreit von "Streuner"-Funktionen. ;)