Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Methodpointer - wie funktioniert's? (https://www.delphipraxis.net/85698-methodpointer-wie-funktionierts.html)

Der_Unwissende 3. Feb 2007 19:20

Re: Methodpointer - wie funktioniert's?
 
[OT]
Zitat:

Zitat von Hawkeye219
der harte TypeCast dürfte aber zu einer Exception führen. Besser wäre es so:
...
Voraussetzung für den Einsatz der Funktion Supports ist aber, daß die Interfaces eine eindeutige GUID besitzen:

Geliebte COM-Interfaces. Da soll nochmal jmd. fragen warum einige der Meinung sind, dass Delphi ebend keine "nativen/echten Interfaces" anbietet
[/OT]

yankee 3. Feb 2007 21:25

Re: Methodpointer - wie funktioniert's?
 
Ok, jetzt habe ich es verstanden :-).
Lediglich entzeiht sich mir der Vorteil etwas...
Ich habe immernoch genausoviel Tipparbeit (naja... eigentlich sogar deutlich mehr), übersichtlicher wird der qt dadurch auch nicht, aber die Ausführungszeit könnte darunter leiden immer noch über eine Klasse zu gehen...

Oder übersehe ich da was?

Der_Unwissende 4. Feb 2007 11:54

Re: Methodpointer - wie funktioniert's?
 
Zitat:

Zitat von yankee
Lediglich entzeiht sich mir der Vorteil etwas...
Oder übersehe ich da was?

Ich weiß nicht warum Du denkst, dass der letzte Weg hier schneller, schöner oder besser sein sollte. Ich hoffe nichts davon je behauptet zu haben, ich sagte nur, dass dies eben der Objekt Orientierte Weg wäre. Natürlich gibt es Dinge die man an dem Ansatz bemängeln kann, aber ich denke dein Argumentation liegt da doch ein wenig daneben. Klar, die Perfomance leidet unter jeder Indirektion und natürlich auch den paar Byte Overhead eines Objekts, aber das sollte sich doch sehr sehr stark in Grenzen halten. Und mehr Tipparbeit, nun ja, würdest Du auf das Einrücken verzichten weil es mehr Tipparbeit bedeutet?! Ich hoffe mal eher nicht, mehr Tipparbeit ist nie ein Kontrapunkt, es geht hier i.d.R. nur um wenige Sekunden mehr oder weniger. Wenn Du das ganze auf die Laufzeit eines Projektes umlegst, dann kommst Du eh auf unheimlich wenige Zeilen Code/Tag, da käme es dann nie auf 10 min mehr oder weniger tippen an. Wichtiger sind immer andere Faktoren.

Die Nachteile liegen klar auf der Hand, Du hast natürlich recht, die Perfomance geht runter. Zudem muss man für jede Methode einen eigenen Wrapper erstellen und auch instanziieren (man kannst natürlich auch eine class-function verwenden, dann dürfte das entfallen). Über die Übersichtlichkeit kann man sich natürlich streiten, ich sehe hier ehrlich gesagt keinen Unterschied ob ich ein Objekt übergebe oder eine Funktion.
Die Vorteile liegen dann vorallem darin, dass Du auf implizite Zeiger verzichtest. Wenn Du mit Pointer arbeitest, kann wirklich alles übergeben werden und Du hast keine Garantie, dass es sich dabei um eine gültige Adresse handelt. Klar, geht bei Objekten auch, aber Du kannst Sicherheiten mit is-Abfragen und für Interfaces natürlich supports-Anfragen schaffen. Natürlich kostet das ganze dann wieder perfomance, aber es geht hier auch nur um die generelle Möglichkeit. Du kannst dann selbst entscheiden was für Dein jeweiliges Problem wichtiger ist.
Es gibt noch die üblichen Vorteile der OOP, die für jeden Wrapper einer Funktion gelten. Du kannst natürlich auch hier super Dinge in den einzelnen Implementierungen verbergen und jedes Objekt enthält nur die Funktionalität, die für die gekapselte Funktion nötig ist (imho übersichtlicher als eine große Klasse mit allen Funktionen). Aber wie gesagt, hier handelt es sich eher um Geschmackssache.
Der eigentlich wichtigste Vorteil dürfte vielmehr darin liegen, dass es sich um ein Design-Pattern handelt. Diese beschreiben sehr eindeutig ein Problem und dessen Lösung. Eine der wichtigtigsten Eigenschaften von gutem Code liegen darin, dass dieser gut Kommentiert wird. Dadurch wird (auf Kosten von etwas mehr Tipparbeit :wink:) eine verbesserte Les-, Wart- und Erweiterbarkeit garantiert. Hier ist es dann wiederum besonders wichtig, dass Du Designentscheidungen ordentlich kommentierst. Was der Code macht kann man immer sehr direkt ablesen, warum Du es aber so machst und nicht anders nicht.

Ok, lange Rede, letztlich bleibt es dabei, dass Du nur sehr subjektiv entscheiden kannst ob ein eher Objekt Orientierter Ansatz Dir Vor- und/oder Nachteile bringt und wo diese liegen. Ich denke (wie gesagt) keineswegs, dass OOP immer toll/überlegen/schneller/besser/schöner ist, aber er hat auch gewisse Möglichkeiten.


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:29 Uhr.
Seite 2 von 2     12   

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