Zugriff auf Objekt in Klasse

[brechi]

Für deinen Fall kannst du auch einen singleton implementieren (oder eine globale variable mit initialization und finalization nutzen), aber auch ich rate dir davon ab...

[jfheins]

Zitat:

Zitat von FediDelPr (Beitrag 1480308)

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...

[TurboMagic]

Zugriff auf nicht erzeugte Objektreferenzen wird eher zeitnah knallen!
Einfach nicht so gegen das Create sträuben!
Du kannst halt auch nicht in der Bibliothek ein Buch ausleihen ohne den Ausleihvorgang irgendwie zu registrieren...

Und was Exceptionbehandlung anbelangt: die ist eigentlich weniger aufdringlich als die klassische
Fehlerbehandlungsmethode.

Warum?

Weil man früher direkt nach jedem Aufruf der schief gehen konnte eine Statusvariable (in Turbo Pascal IOresult,
in SAP's ABAP Sy-Subrc) direkt abfragen musste und dann dort den Fehler gleich behandeln musste weil er sonst
nach dem nächsten Aufruf einer Routine die diese Fehlerbehandlung nutzt überschrieben ist.

Bei Exceptions kann man mitunter auch eine zentrale Behandlung irgendwo implementieren und alle Exceptions
laufen dort auf, egal woher die kommen. Man kann auch Fehler durch unterschiedliche Exception Klassen unterscheiden
und nur die behandeln, die man für relevant hält. Diese Klassen können dann auch zusätzliche Daten die Infos
zur Fehlerursache enthalten bekommen usw. ALles Dinge, die der klassische Ansatz nicht bietet.
Der lenkt vielstärker von der eigentlichen Aufgabe ab als so ein Create Aufruf...