Zugriff auf Objekt in Klasse

[FediDelPr]

@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]

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]

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]

Moin...
Es ist zwar löblich das Üben in einen sinnvollen Kontext zu packen. 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

[FediDelPr]

@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]

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]

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

[jfheins]

Zitat von FediDelPr:

Ich programmiere seit einem halben Jahrhundert (was an und für sich noch nichts
heißen 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 vor allem
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.

Ich kann wenig zu IdIMAP beitragen, aber vielleicht einige generelle Punkte:
- Unsichere / unzuverlässige Software lässt sich in erster Linie mit einem Instrument bekämpfen: Tests. Am besten automatisierte, zuverlässige (deterministische) häufige, umfangreiche Tests.

OOP hat damit nur sehr am Rande etwas zu tun. OOP bietet mMn vor allem eine Gruppierung von Methoden mit einem Zusammenhang an. Wo man "früher" einen struct erstellt hat und dann 7 Funktionen hatte, die den als Parameter bekommen, kann man heute eine Klasse erstellen und die Methoden mit den Daten zusammen in einer Datei ablegen.

Zitat:

Weil das nur ein technisches Problem (endlicher Speicher) ist und nichts mit der eigentlichen
Aufgabe zu tun hat. Es verhunzt die eigentliche Absicht. Die Essenz des Programmes
versinkt in solchen technischen Details. Das Programm ist schlussendlich schlechter lesbar,
es sind mehr Fehler möglich. Natürlich mag das für einen Einzelfall nicht gravierend sein
aber in der Summe.. Eine normale Variable muss man ja auch nicht zuerst kreieren.

Den endlichen Speicher hast du aber quasi immer und überall. Und die Herausforderung ist ja, dass jeder den Speicher anders nutzen will.
Wenn du keine dynamische Speicherallozierung machst, dann musst du für jede Sache beim Compilieren festlegen, wieviele verschiedene Sachen es geben darf. Also Chrome würde bspw. mit maximal 20 Tabs laufen weil das Array hat auf 20 Elemente gesetzt ist. In echt möchte aber der eine Type 50 schlanke Tabs laufen lassen, der zweite nur einen Tab aber der rechnet irre viel und der dritte kauft sich extra 64GB RAM um 500 Tabs parallel anzuzeigen.
Daher gibt es dynamisches Speichermanagement, damit jeder das machen kann, was er will

Und dazu gehört dann auch immer Speicher allozieren und freigeben. Vergleiche einmal Pseudocode:

Code:

var myParams = malloc(TmyParams);
myParams.Recipient = "[e-mail]"
SendEmail(myParams);
Free(myParams);

Code:

var myParams = TmyParams.Create();
myParams.Recipient = "[e-mail]"
myParams.SendEmail();
myParams.Free;

Ist quasi dasselbe, nur anders aufgeschrieben. Das Problem, was hier gelöst wird: Es wird Speicher für Variablen reserviert, die länger leben als ein Funktionsaufruf. Denn letztlich kennt der C und der Delphi Compiler die zwei Optionen: Variable lebt genau so lange wie die Funktion (Stack) oder Variable lebt länger => Heap & Programmierer muss sich darum kümmern, den Speicher wieder aufzuräumen.

Wenn dir das Speichermanagement zuviel wird, würde ich dir eine andere Sprache empfehlen. Eine mit automatischem Speichermanagement. Dann musst du immer noch allozieren, aber nicht mehr freigeben. Die Auswahl ist riesig und wird immer größer. (Mir wäre keine neue Sprache bekannt, die dem Entwickler das aufbürdet) Eine Auswahl:
- Rust
- Javascript / Typescript
- C#
- Kotlin
- Python
- Oxygene?

Der Code wird lesbarer weil du dich um das freigeben nicht mehr kümmern musst.

[TurboMagic]

Automatisches Speichermanagement klingt zwar in der Theorie schön, hat in der Praxis aber durchaus auch seine Tücken.
Ein gutes Beispüiel dafür war die Delphi 2006 IDE...
Denn: der Speicher wird nicht deterministisch sondern meist irgendwann (Ausnahme: ARC) freigegeben.
Bis dahin hat sich etvl. viel "Müll" angesammelt oder die Freigabe passiert zu einem Zeitpunkt wo der Garbage Collector
meint es wäre oppertun, es aber in Wirklichkeit doch nicht ist...