Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Zugriff auf Objekt in Klasse (https://www.delphipraxis.net/206473-zugriff-auf-objekt-klasse.html)

FediDelPr 3. Jan 2021 23:27

AW: Zugriff auf Objekt in Klasse
 
@hoika

Schwanzbeisser:

- Ich möchte möglichst alles in das Modul verpacken, auch das Create!

- Der einzige Zugriff soll (vorderhand) über OpenEmail und CloseEmail erfolgen,
später dann noch Setup, Read und Write. Ich benötige aber gleichzeitig mehrere
EmailProvider, daher mehrere IMAPClients.

Vielleicht hast du weiteren Tipp /Lösungsweg ?

FediDelPr 3. Jan 2021 23:40

AW: Zugriff auf Objekt in Klasse
 
Noch etwas:

Vorderhand, während Entwicklung, möchte ich auch ausserhalb des Email-Moduls
vollen Zugriff auf TidIMAP4 um alle Funktionen des IMAP4 Drivers verwenden
zu können.

hoika 4. Jan 2021 06:28

AW: Zugriff auf Objekt in Klasse
 
Hallo,
Zugriff auf IMAP4 hast du ja durch die Ableitung.
Und mehere Konten = mehrere eigene Klassen, pro Konto eine.

Aber:
Bevor du mit deinen ganzen eigenen Dachen anfängst,
würde ich erst mal alles mit dem originalen Indy TIdImap4 zusammenbauen und dann deine eigene Klasse erzeugen.

haentschman 4. Jan 2021 07:34

AW: Zugriff auf Objekt in Klasse
 
Moin...:P
Es ist zwar löblich das Üben in einen sinnvollen Kontext zu packen. :thumb: Das hilft dir nicht weiter. Du brauchst Grundlagen!
Zitat:

Wenn ich eine Instanz von TEmailCoreObject erzeuge, ist dann das CREATE nur
Jede eigene Klasse muß/sollte einen constructor/destructor haben...auch wenn da erstmal nix drinsteht als inherited.
Was das bedeutet: siehe https://www.delphi-treff.de/tutorial...i-crashkurs/8/ -> Konstruktor
Noch Lesestoff:
https://www.delphipraxis.net/10691-o...inherited.html
:wink:

FediDelPr 4. Jan 2021 17:59

AW: Zugriff auf Objekt in Klasse
 
@hoika
das Arbeiten mit dem Indy TIdIMAP4 funktioniert grundsätzlich.
Nur will ich ein einfacheres und anwenderfreundlicheres Interface dazu.
Gewisse Details dürfen versteckt bleiben.
In den bisherigen Anwendungen zeigte sich was für mich wichtig ist, darum
möchte ich nicht immer den ganzen Ballast mitschleppen.

@hoika, haentschman
Ich programmiere seit einem halben Jahrhundert (was an und für sich noch nichts
heissen will). Es ist einfach so, dass OOP mich noch nicht so richtig überzeugt hat.
Trotzdem will ich den Einstieg jetzt mal definitiv durchziehen. Auch, damit ich mir
selbst ein Bild von den Vor- und Nachteilen machen kann. Bis anhin sehe ich vorallem
die Nachteile.
Bis jetzt habe ich eher den Eindruck von viel Ballast und - was ich hasse: unsichere
und unzuverlässige Software. Wohlverstanden immer mit dem gleichen Aufwand.
Auch bezüglich der besseren Lesbarkeit bin ich noch nicht überzeugt. Aber warten wir ab,
vielleicht komme ich noch auf den Geschmack. Etwas verwundert bin ich auch, dass mir der
Einstieg nicht eins, zwei, drei gelingt. Hat das mit dem Alter, Eingefahrenheit oder
damit zu tun, dass doch nicht alles so logisch und konsistent ist ? Kann auch sein, dass
ich noch nicht die für mich richtige Literatur gefunden habe.
Nun ich mache weiter und werde weitere Fragen stellen.

Bis dahin herzlichen Dank

TurboMagic 5. Jan 2021 08:48

AW: Zugriff auf Objekt in Klasse
 
Hallo,

wenn du die Grundlagen noch sicherer drauf hast, ist's kein wirklicher ballast mehr.
Deine Klasse erbt ja eigentlich alles von der entsprechenden Indy-Klasse, du solltest halt
nur wie schon beschrieben einen Constructor spendieren und in dem inherited aufrufen, damit
der geerbte Constructor der Indy-Klasse auch aufgerufen wird. Dannb rauchst du vermutlich bei
deinen Methoden keine Objektinstanzen mehr als Parameter, das macht dann alles die eigene Klasse.

Allerdings: durch das Erben sind bei deiner Klasse halt auch alle Dinge, welche die Indy-Klasse
als public anbietet weiterhin public.

Wenn dir das nicht passt kannst du alternativ eine Klasse schreiben die nicht erbt, sondern
intern eine Instanz der betreffenden Indy-Klasse nutzt die im COnstructor erzeugt wird und im
Destructor freigegeben wird.

Dann schreibst du nur für die DInge, die bei dir öffentlich sein soll entsprechende Wrapper-Methoden.

Grüße
TurboMagic

freimatz 5. Jan 2021 09:48

AW: Zugriff auf Objekt in Klasse
 
Wenn er kaseln will würde ich das auch eher vorschlagen (https://de.wikipedia.org/wiki/Kompos..._von_Vererbung)

FediDelPr 6. Jan 2021 14:10

AW: Zugriff auf Objekt in Klasse
 
Nun ich gehe jetzt tiefer in die Materie, es bringt ja nichts, wenn ich es nur
halb verstehe. Bin an Übungen mit dem Doberenz Delphi 7 Buch.
Das Tutorial des Delphi-Treffs kann ich nicht mehr runterladen. Weiss jemand wo
das noch möglich ist ?

Zugleich muss ich vorwärts kommen.
Daher nun zu weiteren Schwierigkeiten. Für das aktuelle Problem bin ich nahe am Ziel.
In der folgenden Version läuft's nämlich:

Code:
(* Deklaration und Aufruf *)

VAR
  IMAPClientEx: TEmailCoreObject;
  ...

 BEGIN
   IMAPClientEx := TEmailCoreObject.Create(NIL);
   IMAPClientEx.OpenEmail;
   ..
   ..
 END;

(* Klassendefinition und Implementation (in eigenem Modul) *)
TYPE
  TEmailCoreObject = CLASS(TidIMAP4)
  PRIVATE
    (* Private-Deklarationen *)
    ..
  PUBLIC
    (* Public-Deklarationen *)
    PROCEDURE OpenEmail;
    PROCEDURE CloseEmail;
  END;
Es wurde mir klar, dass die 'Übergabe' einer Instanz eigentlich einer Parameterübergabe
entspricht. Daher können auch die Parameter in OpenEmail usw.entfallen. (wie von TurboMagic gesagt)

Was mir an dieser Realisierung noch nicht passt, ist, dass das Create im Aufrufteil
stattfindet. Das muss in das Modul mit der Klassendefinition rein. Wie dieses Create-Zeile
aussieht ist mir noch nicht klar. Der Compiler frisst zwar folgendes, aber die Referenz der Instanz
verschwindet natürlich im Nirvana.

Code:
(* Deklaration und Aufruf *)

VAR
  IMAPClientEx: TEmailCoreObject;
  ...

 BEGIN
   IMAPClientEx.OpenEmail;
   ..
   ..
 END;

(* Klassendefinition und Implementation (in eigenem Modul) *)
TYPE
  TEmailCoreObject = CLASS(TidIMAP4)
  PRIVATE
    (* Private-Deklarationen *)
    ..
  PUBLIC
    (* Public-Deklarationen *)
    PROCEDURE OpenEmail;
    PROCEDURE CloseEmail;
  END;

PROCEDURE OpenEmail;
 BEGIN
   TEmailCoreObject.Create(NIL); (* geht nicht, funktionierende Alternative ? *)
   ..
   ..
 END;
Vielleicht hat das jetzt mit dem anscheinend notwendigen (oder mindestens empfehlenswerten) CONSTRUCTOR
zu tun? Auch das SELF könnte ein Kandidat zur Lösung des Problems sein.

Grüsse

TiGü 6. Jan 2021 14:29

AW: Zugriff auf Objekt in Klasse
 
Die Tutorials gehen doch? Zumindest kann ich problemlos z. B. das folgende aufrufen:

https://www.delphi-treff.de/tutorial...i-crashkurs/8/

Delphi-Quellcode:
(* Deklaration und Aufruf *)

// jeder soll formatieren wie er kann und mag, aber dieses UPPERCASE der Schlüsselwörter ist irgendwie ganz schwer
// TurboPascal aus den Achtzigern. Da wird der Bildschirm vor dem inneren Auge schwarz und die Schrift giftgrün
// und auf auf 80 Zeichen pro Zeile begrenzt ;-)

VAR
  IMAPClientEx: TEmailCoreObject;
  ...

 BEGIN
   IMAPClientEx := TEmailCoreObject.Create(nil);
   IMAPClientEx.OpenEmail;
   ..
   ..
  // wenn fertig, freigeben:
  IMAPClientEx.Free;
 END;

(* Klassendefinition und Implementation (in eigenem Modul) *)
TYPE
  TEmailCoreObject = CLASS(TidIMAP4)
  PRIVATE
    (* Private-Deklarationen *)
    ..
  PUBLIC
    (* Public-Deklarationen *)
    PROCEDURE OpenEmail;
    PROCEDURE CloseEmail;
  END;

PROCEDURE TEmailCoreObject.OpenEmail; // < - - - - Hier die Änderung beachten
 BEGIN
   // hier jetzt die eigentliche Logik implementieren.
   ..
   ..
 END;

FediDelPr 6. Jan 2021 14:38

AW: Zugriff auf Objekt in Klasse
 
@TiGü und andere

Entschuldigung, das habe ich unvollständig kopiert bzw. abgeschrieben.
Das ist schon mit der Klasse vorne dran.


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:15 Uhr.
Seite 2 von 4     12 34      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz