AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Methodpointer - wie funktioniert's?

Ein Thema von yankee · begonnen am 3. Feb 2007 · letzter Beitrag vom 4. Feb 2007
Antwort Antwort
Seite 2 von 2     12   
Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#11

Re: Methodpointer - wie funktioniert's?

  Alt 3. Feb 2007, 19:20
[OT]
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]
  Mit Zitat antworten Zitat
Benutzerbild von yankee
yankee

Registriert seit: 10. Mär 2004
1.134 Beiträge
 
Lazarus
 
#12

Re: Methodpointer - wie funktioniert's?

  Alt 3. Feb 2007, 21:25
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?
Letzter Tipp: Drogen. Machen zwar nicht glücklich, geben einem aber wenigstens das Gefühl glücklich zu sein.

Have a lot of fun!
  Mit Zitat antworten Zitat
Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#13

Re: Methodpointer - wie funktioniert's?

  Alt 4. Feb 2007, 11:54
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 ) 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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:24 Uhr.
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