OOP: Vererbung von Konstruktoren

[woki]

Zitat:

Zitat von Robert_G

Du kannst aber mit protected ins nächste offene Messer laufen...
Die (etwas schlampige) Implementierung von protected in Delphi ähnelt ein wenig dem internal aus c#.
Alle protected Felder/Methoden sind für alle Klassen innerhalb der Unit sichtbar!

Das ist keine schlampige Implementierung sondern Absicht, und zwar als Ersatz für das Friend-Klassen Konzept in C++.

[Muetze1]

Beschimpfungen (per ICQ zu diesem Beitrag, bisher noch nicht hier im Forum) brauch ich nicht - dann lass ich es lieber bleiben hier mich zu äussern.

[jbg]

Zitat:

Zitat von Muetze1

Im Normalfall sollten die Contructoren auch als Virtual gekennzeichnet werden, damit ein überschreiben möglich wird.

Bist du dir da ganz sicher? Ich hoffe du weißt für was virtuelle Konstruktoren gut sind.

[Hansa]

Zitat:

Zitat von Muetze1

PS: Die angesprochene Warnung kommt bei euch nicht, da ihr bisher immer wieder neue Constructoren gebildet habt anstatt den vorhandenen der Vorklasse zu verändern...

Jetzt aber mal langsam. Willst du wirklich behaupten, bei neu eingeführten private Feldern einer Klasse dürfe man nicht den vorhandenen Constructor erweitern ? :shock: Sondern man solle den der Vorklasse verändern ? :gruebel: Dann müßte ich total umlernen und hätte bisher alles falsch gemacht. Seltsamerweise funktioniert bei mir alles und Warnungen habe ich in dem Zusammenhang auch keine. Und ich verwende fast nur OOP in nicht gerade kleinen Programmen. Sollte immer der Constructor der "Vorklasse" geändert werden müssen, egal ob man ihn jetzt Constructor nennt, oder eher ein Create meint, so müßte ich in einer Hierarchie von 20 Klassen aber ganz schön viel unnötigen Balast mitschleppen.

Und was Komponenten angeht so suche ich die nur selten. Lieber baue ich mir die selber. Da steckt auch viel OOP drin.

[woki]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Nonsense

Zitat:

Zitat von Luckie

Befindest du dich in der gleichen Unit? Innerhalb der gleichen Unit sind auch private Felder einer Klasse für andere sichtbar.

Hat das einen tieferen Sinn? Irgendwie etwas verwirrend, weil ich keinen Sinn erkennen kann.

Ich denke mal der "Sinn" dahinter ist, dass IMHO ca. 50% der Delphi-"Programmierer" keinerlei Ahnung von OOP haben. Wenn sie dann doch etwas OOP programmieren wollen, wollen sie's wohl so simpel wie möglich -> so müssen sie sich keine Gedanken über die Sichtbarkeit innerhalb einer Unit machen.
Du kennst doch die typischen Fragen in der DP: "Gibt's 'ne Komponente hierfür?", "Gibt's 'ne Komponente dafür?", ... :roll:
Da Delphi darauf abzielt VB'ler zu bekehren ist diese Implementierung gar nicht so unverständlich. ;) VB ist halt alles andere als OOP. :P

Nachtrag:
@Hansa, das ist jetzt nicht dein Ernst, oder?

@Nonsense: Das Verahlten der IDE macht Sinn, auch wenn Du es im Moment nicht verstehst. Ich kann jetzt hier kein Tutorial über den Sinn des Konzeptes von Friendklassen machen, aber es ist ein akzeptiertes Konzept in der OOP, ich persönlich habe noch nie gehört das jemand gesagt hat, das war ein Fehler. Ich denke,am sichersten kommst du zu mehr Informationen und Verständnis dafür, wenn du nach Friend - Klassen suchst, bei dem Delphi - Ersatzkonzept dafür würde mir jetzt kein Stichwort einfallen.

@Robert_G:
Wenn man auf ein Konzept stößt, das einem das Gefühl vermittelt, man habe OOP besser verstanden als Anders H., dann sollte man vieleicht in sich gehen, und darüber nachdenken,ob man sich nicht gründlich auf dem Holzweg befindet. Delphi - Language (Objekt-Pascal) basiert auf einem sehr gut durchstrukturierten und sauber umgesetzten OOP - Konzept. Und es ist kein Kompromiß für OOP-Unfähige Entwickler. Man kann in Delphi zwar genau wie in C++(Builder), Java, oder C# zwar auch eine Menge erreichen, indem man Obejktbasiert statt Objektorientiert entwickelt, das läßt aber keine Rückschlüsse auf die Qualität des Grundkonzeptes zu. Und das ist in Delphi nach wie vor sehr gut. Im Gegenteil, die Möglichkeit, Komponenten durch verschiedene Techniken an einen bestimmten Zweck anzupassen statt immer sofort neue Klassen ableiten zu müssen ist gerade eine Stärke des Konzeptes.
Es ist auch ein horrender Blödsinn, zu behaupten es gäbe hier irgendwelche Kompromisse, um VB-Entwicklern zu gefallen.

Die Frage, gibt es eine Komponente hierfür oder dafür, zeigt lediglich daß jemand das Grundkonzept moderner Softwareentwickung verstanden hat (wenn vielleicht auch unbewußt), mit dem diese versucht, erwachsen zu werden. und versucht die Quote gescheiterter Projekte unter die 80% Marke zu drücken. Der goldene Grundsatz lautet, 'Never make it, if you can buy it'. Was glaubst du. was jeder Projektleiter oder Budgetverantwortliche der seinen Job versteht, einem Anwendungsentwickler erzählt, der eine Komponente, die er in einer halben Stunde downloaden und einsetzen kann, mit einem Aufwand von einer oder mehreren Mannwochen selbst entwickelt.

Grüße
Woki

[Robert_G]

Uff :shock: , das klang doch schlimmer als es tatsächlich gemeint war.
Mein rüder Tonfall kam wohl gestern durch eine Diskussion mit einem VB'Ler, der mir vorwerfen wollte: Ich arbeite ineffizient, weil ich eine WebControl-Abgeleitung gebastelt habe anstatt mein WebForm mit Repeatern zuzumüllen. (Es kostete mich fast unmenschliche Selbstbeherrschung, ihn deshalb nicht auszulachen.)

@Topic
Nachdem ich von 2 erfahrenen Delphianern hören musste, dass das Sinn macht muss ich mich natürlich geschlagen geben. Da war ich wohl gehörig auf dem Holzweg. :oops:
Ein hübsche Implementierung ist es trotzdem nicht. Ein extra Access modifier á la internal wäre da ... "netter".

p.s.:
@Muetze, ärgere dich nicht über Hansa -> das bringt nix ;)
Und zu deinem Einwand: Der Code hatte tatsächlich nicht viel mit OOP zu tun. Es ging mir eigentlich nur um das da:

Delphi-Quellcode:

// hier hätte er meckern sollen 
inc(fX);

p.p.s.: Ich glaube trotzdem, dass Delphi versucht VB'lern zu "gefallen". :mrgreen:

[woki]

Zitat:

Zitat von Robert_G

p.p.s.: Ich glaube trotzdem, dass Delphi versucht VB'lern zu "gefallen". :mrgreen:

Aber indem man ihnen etwas bietet, was die Vorteile von VB (in der Epoche "Ante Dot NET") aufweist, ohne Ihnen diegleichen Kompromisse aufzuzwingen. Und es wendet (wandte) sich genauso an C++- Anwendungs-Enwickler, deren Projekte in Schönheit sterben, weil die zehnmal höheren Projektkosten (Schätzung eines Freundes von mir, der von Haus aus C++-Entwickler ist und seine erfolgreiche Bildverarbeitungsfirma in seiner Nische an die Weltspitze geführt hat) nicht bezahlbar sind.

Grüße
Woki

[LarsMiddendorf]

Zitat:

Ein extra Access modifier á la internal wäre da ... "netter".

Ab Delphi 8 gibt es dafür dann strict private und strict protected. Das entspricht dann dem private und protected aus C++/C#, wobei das normale private ja faktisch zumindest auf unit Ebene wie das internal ausgewertet wird.