Komponente von TCustomSocket ableiten?

[Hansa]

Zitat:

Zitat von IngoD7

...Dass dir die Stille einer leeren virtual-Methode lieber ist, als der klare Hinweis auf eine fehlerhafte Klassenprogrammierung, wundert mich nun schon etwas.

Schon mal versucht, eine abstracte Methode zu debuggen ? Viel Vergnügen. :lol:

Und wenn wir schon dabei sind : wo liegt der entscheidende Vorteil, ohne die Nachteile in Kauf zu nehmen ?

[Robert_G]

Das dürfte in jedem 2. Beitrag hier stehen. :roll: (oder anders ausgedrückt: Jedem, der nicht von dir ist. :mrgreen: )

[IngoD7]

Zitat:

Zitat von Hansa

Schon mal versucht, eine abstracte Methode zu debuggen ?

Du meinst, wenn ein EAbstractError ohne weitere Hinweise und ohne definierten Stop im Quelltext kommt?
Nun, wenn man beim sinnvollen Gebrauch von abstract-Methoden die Warnungen des Compilers nicht in den Wind schlägt, ist das möglich, bzw. der Fehler dürfte gar nicht erst passieren.

Zitat:

[Warnung] Unit1.pas( 48 ): Instanz von 'TAbleitung' mit der abstrakten Methode 'TBasis.TestProc' wird angelegt

Wenn man z.B. eine fremde Unit einsetzt, die tatsächlich notwendige Implementierungen in Ableitungen auslässt (ist ja schon grober Frevel!), dann ist mir die Fehlermeldung immer noch lieber, als ein stillschweigendes Gar-Nichts-Machen bei deiner leeren Virtuell-Methoden-"Lösung". Das führt dann nämlich zu Logikfehlern im Programm und/oder erst später zu Programmabbrüchen, die genau so schwer zu orten sind. Ursache ist ja immer noch die vergessene Implementation einer Methode.

Ne, ne, dann lieber eine klare Fehlermeldung, die mir deutlich sagt: Mit dieser Klasse stimmt was nicht!

Zitat:

Zitat von Hansa

[...]irgendwann habe ich die Implementation dieser Prozedur tatsächlich vergessen.[...]und ich verwende "virtual" statt "abstract" und schreibe notfalls in der Ur-Klasse nur :

Delphi-Quellcode:

begin end;

Seitdem ist Ruhe.

Wie oben geschrieben: Ruhe ist das allerletze, was ich bei einer derart fehlerbehafteten Klasse haben möchte. :cyclops:

[Muetze1]

Moin!

Ach, Diskussionen mit Hansa sind immer wieder witzig und mich muss mich hier allen (ausser Hansa) mal anschliessen: Die abstrakten Methoden haben vor allem Vorteile und bisher sehe ich keine direkten Nachteile. Warnungen und Hinweise sind neben Fehlern eine wichtige Ausgabe des Compilers und sollten/müssen wahrgenommen werden.

Und eins kann ich dazu sagen: Wenn einer stillschweigend irgendwo mal Begin/End; hinschreibt weil er mit abstrakten Methoden nicht umgehen kann, dann ist dies schon grob fahrlässig. Da suchen nachher vielleicht 2 Programmierer fast 3 Tage um so eine leere Funktion zu finden um dann festzustellen, das ein anderer in der Ableitung mit der Methode nix gemacht hat. So ein teuren Spass wird sich keine Firma zweimalig leisten. Derjenige darf danach entweder nur noch Dokumente klammern oder Kaffee kochen - je nachdem welcher der vorherigen Ex-Programmierer woanders eine Stelle gefunden haben... :mrgreen: .

MfG
Muetze1

[Hansa]

Hi Theoretiker :

programmiert eine abstrakte Klasse. Dann leitet ihr davon eine andere ab und noch 2 weitere. Immer schön abstrakt. :mrgreen: Und dann baut ihr irgendwo mittendrin etwas nicht definiertes ein. Und dann ? 8) Abstrakte Klassen sind hier im Hause jedenfalls zum Eigenbedarf wegen Sinnlosigkeit durchgefallen. Thats it.

[Muetze1]

Moin!

Zitat:

Zitat von Hansa

Und dann baut ihr irgendwo mittendrin etwas nicht definiertes ein. Und dann ?

Das passiert dir genaus bei virtuellen Methoden wenn du diese z.B: in einer Klasse mitten drinne abänderst bzw. das Originale versteckst - das Beispiel hat rein gar nix mit den abstrakten Klassen zu tun.

Ausserdem haben die 2. und 3. Ableitung nix mehr mit den abstrakten Methoden der Basisklasse am Hut, da sie die erste Ableitung implementiert. In den Ableitungen 2 und höher kannst du machen was du willst - ableiten oder auch nicht...

Zitat:

Zitat von Hansa

Abstrakte Klassen sind hier im Hause jedenfalls zum Eigenbedarf wegen Sinnlosigkeit durchgefallen. Thats it.

Omg, dann sag uns noch schnell wie das Haus heisst und ich weiss wo ich mich freiwillig nicht bewerbe... :mrgreen:

MfG
Muetze1

[Hansa]

@Mütze : nicht rumoren. 8) "Abstract" trägt nicht dazu bei, etwas zu verbessern. Also los : wo liegt der definitive Vorteil davon. Erwarte Antwort. :mrgreen:

[Muetze1]

Moin!

Zitat:

Zitat von Hansa

@Mütze : nicht rumoren. 8) "Abstract" trägt nicht dazu bei, etwas zu verbessern. Also los : wo liegt der definitive Vorteil davon. Erwarte Antwort. :mrgreen:

Soll ich dir jetzt (fast) alle Beiträge quoten aus diesem Thread??

Der definitive Vorteil: Du hast als Basisklassenprogrammierer die Sicherheit, das die Methode implementiert wird in der Ableitung - ausser natürlich man schlägt alle Warnungen und Hinweise des Compilers in den Wind...

MfG
Muetze1

[Chewie]

Versuch einem Blinden nicht das Sehen zu erklären, Muetze. Ich glaube, er WILL es nicht verstehen :? .

[IngoD7]

Zitat:

Zitat von Muetze1

Der definitive Vorteil: Du hast als Basisklassenprogrammierer die Sicherheit, das die Methode implementiert wird in der Ableitung - ausser natürlich man schlägt alle Warnungen und Hinweise des Compilers in den Wind...

Exakt!
Oder aus einer anderen Richtung betrachtet:
Ist eine Klassenfamilie erst einmal sinn-, ziel- und funktionsgerecht fertig programmiert, so ist es dem Programmierer, der sie einsetzt, wurscht, ob abstrakte Methoden darin vorkommen oder nicht. Sie tut, was sie soll, und gut.

Die Verwendung von abstract soll und kann aber dem Klassenprogrammierer bei der Entwicklung (und Erweiterung) dieser Klassenfamilie helfen, überhaupt da hin zu kommen, nämlich sie fehlerfrei zu gestalten. Und wenn sie fehlerfrei ist, so kommt es auch zu keinen Abstract-Fehlern, die man debuggen müsste.

Ich verstehe daher, Hansa, deine Sorgen bzgl. des "Debuggen von abstrakten Methoden" nicht.

a.) Als Programmierer, der eine fertige Klassenfamilie in seinem Projekt einsetzt, sagt dir ein Abstract-Error, dass die Klassen Schrott sind, weil der Klassenprogrammierer wohl geschlafen hat. Sei dann froh, dass es dir gemeldet wurde, nimm es zur Kenntnis, und verzichte auf die Klassen.
b.) Als Klassenprogrammierer sagt dir ein dabei auftauchender Abstract-Error, dass du Mist gebaut hast. Sei dann froh, dass es dir gemeldet wurde, nimm es zur Kenntnis und korrigiere deine Klassen, damit sie anständig funktionieren.

Somit ist doch der Abstract-Error in jedem Fall eine Hilfestellung zur fehlerfreien Programm- und Klassenerstellung.