Einzelnen Beitrag anzeigen

Benutzerbild von jfheins
jfheins

Registriert seit: 10. Jun 2004
Ort: Garching (TUM)
4.579 Beiträge
 
#32

AW: Zugriff auf Objekt in Klasse

  Alt 10. Jan 2021, 10:25
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 = "a@b.com"
SendEmail(myParams);
Free(myParams);
Code:
var myParams = TmyParams.Create();
myParams.Recipient = "a@b.com"
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.
  Mit Zitat antworten Zitat