Es gibt keine allgemeingültige Regel wie und von wem Kreis und Ellipse abgeleitet werden. Es kommt immer auf die praktische Aufgabenstellung an.
Darum geht es doch in der OOP(Gerade bei der Vererbung), dass man von einander Ableitet und Gemeinsamkeiten finden um den Coder nur einmal zu schreiben.
Von daher kann diese akademische Diskussion bis ins Allerletzte diskutiert werden. Für die Praxis in der Softwareentwicklung ist das nicht relevant.
Es mag aber ähnliche Probleme im Alttag geben. Die sich nicht so leicht oder vielleicht gar nicht lösen lassen.
Weil eine Ellipse eben nicht die Sonderform eines Kreises, sondern ein Kreis die Sonderform einer Ellipse ist.
Das ist der Punkt. Ein Auto ist zwar kein Fahrrad, aber beides sind Fahrzeuge. Ein Kreis und eine Ellipse sind beides Figurieren, die durchaus Gemeinsamkeiten haben.
Sie haben z.b. ein X und Y. Die Größe müsste aber schon Dynamisch sein. Weil eine Line z.b. im Prinzip auch nur eine Stärke hat.
Und schwubs habe ich um ein einfaches Viereck zu definieren 4 Vererbungsebenen... Dein Ernst?
Mein Vater sagte mal: Ist doch ganz einfach, per Winkel das ganze zu beschreiben und ein Kreis besteht dann aus sehr vielen Winkeln oder wie?
Nee, gerade dieses akademisch gern verwendete Viereck-Beispiel zeigt doch, wie man sich mit OOP schön selber ins Knie schießen kann und noch stolz drauf ist.
Ich denke, solche Aufgaben kommt bestimmt in irgendeiner Prüfung vor.
Man schießt sich dann mit OOP ins Knie, wenn man ahnungslos drauflosprogrammiert und nicht versteht wie es funktioniert. Aber das ist auch ohne OOP der Fall.
Naja.... Wie möchtest du denn hier Gemeinsamkeiten finden, ohne Zusagen: Das geht nicht. Z.B. wenn der Datentyp Automatisch erkannt würde, wie in etwa bei Rust, könnte man eine Variable wie Größe hinzufügen und das ist dann entweder nur ein Wert z.b. der Radios oder eben es sind zwei werte. Wäre aber auch unschön, da der Name ja "Größe" bzw. "Size" wäre.
Die OOP ist schon verdammt praktisch. Ich kann mir GUI-Programmierung ohne OOP ehrlich gesagt gar nicht vorstellen.
Da stimme ich dir zu. Es gibt einfach Anwendungsfälle, die geht nur sehr schwer ohne die OOP, wenn man es doch versucht, kommt sowas wie WinAPI dabei raus.
Iteriert man nun durch die Liste, wie es in der Procedure "WriteValues" getan wird, dann wird je nach abgeleiteter Klasse eine andere Funktion "GetValue" aufgerufen.
Das ist ja auch gewollt.
An der Stelle im Code wo das geschieht, ist aber nicht sichtbar, welche abgeleiteten Klassen überhaupt im Spiel sind. In Lazarus wird bei Klick auf "GetValue" die Deklaration von GetValue der Basisklasse gezeigt, obwohl die ja von der abgeleiteten Klasse überschrieben wurde. Lazarus kann da nichts dafür, es ist ja erst zur Laufzeit bekannt, welche Instanzen in der Liste sind. Aber es macht die Sache trotzdem recht unübersichtlich, insbesondere, wenn die abgleiteten Klassen in veschiedenen Units verteilt sind.
Das meine ich. Bei sehr Dynamischen Code, ist nicht immer klar, welche Klassen verwendet werden.
Das kann in der Tat verwirren. Passiert mir übrigens nicht, da ich fast immer nur Interfaces benutze.
Bei interfaces stört mich eigentlich, dass man sämtliche Methoden die dort Definiert sind, ebenfalls definieren muss.
Was für Vorteile bringen Interfaces gegenüber Klassen?
Da komme ich dann beim Klick auf die Methode zu gar keiner Implementierung.
Auch eine Lösung.
Tatsächlich sollte das einen Entwickler auch nicht stören. GetValue wird ja nur in einer Schicht aufgerufen, die über der Klasse liegt in der die Methode implementiert wird. In dieser Schichte sollte aber (sofern alles korrekt getrennt wurde) völlig unerheblich sein, wie diese Implementierung aussieht.
Wenn du einen Fremden Code hast und ihn verstehen möchtest, sind solche Eigenarten aber doch nicht auf einen Blick zu erkennen, ich selbst habe damit im Prinzip kein Problem. Ich finde mich in den meisten fremden Code's sehr gut zu recht. Auch wenn sie etwas komplexer geschrieben sind.
Das ist kein Problem der OOP. Sondern ein Problem der IDE. Und ein Problem jedes Quellcode mit mehr als ein paar 1000 Zeilen. (egal welche Sprache/Konzept)
Ich würde sagen, dass wäre ein Problem der Strukturierung vom Code. Wie erstelle ich guten Code in einem Umfangreichen Projekt ohne die Übersicht zu verlieren?
Die IDE kennt ja alle Möglichkeiten ("Find Identifier References"). Die IDE könnte die zur Wahl anbieten.
Die IDE könnte sich auch merken, wenn man vorher bereits in einer abgeleiteten Klasse war, und weiter navigiert.
Wenn du andere IDE'S wie in etwa Arduino(gut ist keine Wirkliche IDE), verwendest lernst du solche Funktionen zu schätzen. Bei Arduino muss ich immer selbst die passende Datei in einem externen Editor anschauen, wenn ich etwa wissen möchte welche Methoden eine Klasse hat.
Die Code-Vervollständigung, die es jetzt gibt kann man praktisch noch nicht verwenden. Außerdem hat es mich überrascht: Arduino öffnet bei mir über 16.000 Dateien, die scheinbar alle was mit Java zu tun haben, ist mir mal per Zufall aufgefallen Google-Chrome Öfffnet ca 600 und Telegramm 300.
In der prozeduralen Programmierung gibt es pointer auf Funktionen. Da kann man auch nicht sehen wo das Programm wirklich hin springen wird.
Und bei anderen Programmierkonzepten gibt es auch solche Punkte.
Ich finde Pointer als sehr unsicher, sind aber auch sehr Mächtig. Damit kann man den Compiler schön durcheinander bringen.