Moin Hagen,
Zitat von
negaH:
Ich betrachte Exceptions und Schutzblöcke erstmal aus rein syntaktischer Sichtweise,also unabhänig von C/C++ oder den Hardware Exceptions in den Intel CPU's.
Oki.
Zitat von
negaH:
Gewagte These
Warum sollte in der
OOP nur mit Methoden gearbeitet werden ? Im gegenteil wenn die
OOP eine Weiterentwicklung der proceduralen Programmierung darstellt so sollte die
OOP alle wichtigen Funktionalitäten davon auch erben. Ergo: Funmktions-Methoden mit Rückgabewerten sind ein fester Bestandteil der
OOP.
Methoden sind ja noch Funktionen, aber eben Funktionen von Objekten (oder abstrakter, von Klassen). Die Erbfolge ist also durchaus eingehalten.
Zitat von
negaH:
Mein Argumentation basiert auf der Idee der Abstraktions-Ebenen innerhalb eines Programmes. Es gibt Funktionale Bereiche in der Sofwtare die auch heute noch procedural programmiert sind, siehe die
RTL eines Delphi programmes. Dann gibt es andere Bereiche wie die
VCL, deren unterteilung in reine
OOP Überbaue und deren interne Zugriffe auf ordinäre Windows
API procedurale Schnittstellen.
Verstehe ich. Aber genau an dieser Stelle finde ich die obige Diskussion etwas verworren, weil ständig die Konzepte von
OOP und prozeduraler Programmierung (nicht nur von dir!) durcheinandergeworfen werden.
Zitat von
negaH:
Das
Exception Handling muß sich hier nun auf sinnvolle Weise integrieren. Und damit kommen wir zu dem Punkt das man in
RTL Funktionen zb. mit Rückgabewerten statt Exceptions arbeiten sollte. Das ist meine ganz persönlich Erfahrung, wohlgemerkt.
Bei
RTL-Funktionen hast du ja sowieso keine Wahl. Bei Zugriff auf die
Win32-
API ebenfalls nicht. Aber dennoch kann man ja all das kapseln (
VCL und MFC sowie WinForms sind der beste Beweis dafür).
Zitat von
negaH:
Nein sehe ich nicht so, ganz im Gegenteil ->
OOP kann mehr als procedurale Programmierung und Exceptions können mehr als EXIT's. Exceptions sollten
OOP konform sein und sind in fact eine Notwendigkeit in der
OOP.
Ja, du beschränkst aber dogmatisch die Einsatzgebiete für Exceptions auf "Fehler signalisieren" - so verstehe ich deine obige Aussage. Daher mein Einwand. Denn Exceptions können weit mehr.
Zitat von
negaH:
Somit unterstützt deine Gegenbehauptung nur meine ursprüngliche Aussage
Denn du hast Recht damit das
Exception viel mehr können als das was in reine proceduraler Programmierung machbar ist, das bestereite ich garnicht sondern bestätige es durch meine Aussage.
... du hast zuviel Schopenhauer gelesen
Zitat von
negaH:
Jain
Ja im Sine von Erfahrungen die ich gemacht habe das viele Programmierer das
Exception Konzept viel zu eng sehen. Sie sehen es ausschließlich als Fehlerbehandlung.
Nein im Sinne von den konzeptionellen Möglichkeiten die Exceptions bieten, da gebe ich dir absolut Recht.
Puh, ich dachte schon ...
Zitat von
negaH:
Nur ! was ist das Ziel eines guten Source ? Die Wiederverwendbarkeit und Wartbarkeit durch andere Programmierer.Wenn ich nun ein bischen "intelligenter" programmiere andere aber weniger "intelligent" eben einseitig Exceptions begreifen, WER von beiden sollte besser in der Lage sein seinen eigenen Stilso anzupassen das alle Programmierer den Source verstehen ? ich meine das der "intelligentere" Programmierer anpassen sollte. Und exakt so ist meine Aussage zu verstehen: um häufige Missverständnisse im
Exception handlingzu vermeiden sollte man diese nach Möglichkeit wirklich nur zur Fehlerbehandlung benutzen, rein als willkürliche Festlegung.
Na ich denke mal, daß man Wartbarkeit nicht primär darauf ausrichten sollte, daß ein anderer Programmierer den Code warten kann, man selber reicht schon in der Betrachtung.
Du hast ja durchaus recht damit, daß es sein kann, daß jemand anderes nicht so smart ist, aber rechtfertigt das, den Code konzeptionell schlechter zu gestalten? Denn wenn ich
OOP und prozedurale Programmierung schlecht verquicke, wird dies am Ende mehr Probleme machen.
Zitat von
negaH:
Nun,
OOP ist eine Form der prozeduralen Programmierung, ohne deren Gundlagen gäbe es keine
OOP. Das dürfte Fakt sein.
Nein und Ja. Natürlich gäbe es ohne PP kein
OOP, aber
OOP ist - benutzen wir die Metapher der Vererbung - ein Kind der PP. Und nur weil du das Kind deiner Mutter bist, bist du nicht eine andere Mutter - der gemeinsame Nenner besteht darin, daß du als Mensch klassifiziert wirst.
Zitat von
negaH:
Wenn aber die
OOP nur eine andere Form des prozeduralen Konzeptes ist, dann ist die
OOP nur eine Fortführung der guten Eigenschaften der prozeduralen Mittel der Programmierung. Man darf und kann beides nicht voneinander trennen.
Wes Grundes? Man sollte sie sogar trennen um konsequent zu bleiben. Vorteil von
OOP ist ja gerade nicht, daß der Laufzeitcode soviel optimierter ist als der von PP-Programmen (das macht eh der Compiler), sondern vielmehr die Wartbarkeit gesteigert wird, weil ein Bug in einer "Elternklasse" gefixt werden kann und die "Kindklasse" diesen Fix erbt. Das Ganze wird dann dank Geheimnisprinzip und Polymorphie noch scharf angerichtet und ist so ein sehr leckerer Mix für den Programmierer. Manche mögen's halt nur nicht scharf
Es ist richtig, daß man manchmal nicht umhinkommt Funktionen im alten Stil zu benutzen - ebenso finde ich es hirnrissig sowas wie Integer als Klassen zu betrachten (Java), aber im Gesamtkonzept sind auch dies Puzzlesteine, welche es erlauben weit komplexere Programme zu schreiben.
Zitat von
negaH:
Und mal ehrlich, gerade du müsstest wissen wie Objekte/Klassen in Delphi wirklich funktionieren und du weist auch das man mit rein prozeduraler Programmierung in PASCAL auf jedem Record + Proceduren die Funktionaliät der
OOP nachbilden kann. Das Einzigste was dann fehlt ist die erweiterte Unterstützung des Programmieres duch den Compiler selber.
Das ist richtig. Kann man in fast allen
OOP-Sprachen (die ja meist von einer PP-Sprache abstammen) finden.