Hallo, ich habe eine Klasse geschrieben die verschiedene rudimentäre Sachen berechnen und ausgeben kann. Davon will ich einige Objekte erzeugen (für jeden Datensatz eine). Jetzt brauch ich noch eine Klasse welche Funktionen bereitstellt umd die Datensätze zuvergleichen, bzw. deren Berechnungen zuvergleichen. Mir ist das Klassenkonzept nicht so ganz klar. Die Klassen haben glaube ich nichts miteinander zu tun, außer das die "Oberklasse" nur Objekte der anderen Klasse verwaltet und vergleicht. Macht es jetzt Sinn die eine Klasse von der anderen abzuleiten? Sie wird eh keine Memberfunktionen übernehmen. Wie mache ich die Klassen untereinander bekannt? Geht um Matlab, aber das Verständnisproblem ist ja sprachen unabhängig. Danke
Schau mal bei Deinem Problem besser in die Richtung Überladen von Operatoren. Denn so kannst du z.B für einen Operator wie "==" eine Implementation für deine eigene Klasse schreiben, und dann den entsprechenden Operator auf Instancen deiner Klasse anwenden.
Klasse schrieb: > Jetzt brauch ich noch eine Klasse welche Funktionen bereitstellt umd die > Datensätze zuvergleichen, bzw. deren Berechnungen zuvergleichen. Wieso soll das Deine Klasse nicht selbst können? Die weiß am besten, wie ihre Daten strukturiert sind, die kann auch auf private/protected-Member zugreifen, und eine Funktion à la "Vergleiche das eigene Objekt mit einem (per Referenz oder Pointer) übergebenem anderen" ist leicht geschrieben.
Klasse schrieb: > Mir ist das Klassenkonzept nicht so ganz klar. > Die Klassen haben glaube ich nichts miteinander zu tun, außer das die > "Oberklasse" nur Objekte der anderen Klasse verwaltet und vergleicht. Wenn Du verschiedene Hunde hast (normale, welche die sprechen können und sogar Hunde die fliegen können) dann erben die alle von der Basisklasse Hund (weil bellen und beißen können sie alle). Und das einzige Pferd in Deinem Zoo und der Hund erben beide von Vierbeiner. Der Dompteur jedoch der die Hunde trainiert hat kaum was mit diesen gemeinsam. Außer vielleicht die Grundfunktionen aus der Klasse Säugetier, davon sind auch die Vierbeiner abgeleitet. Nur nicht der Hundezwinger, der ist aus Metall und somit ganz was anderes, der ist komplett separat, eventuell ist er aber entfernt mit dem Pferdestall verwandt.
Rufus Τ. Firefly schrieb: > Wieso soll das Deine Klasse nicht selbst können? > Die weiß am besten, wie ihre Daten strukturiert sind, die kann auch auf > private/protected-Member zugreifen, und eine Funktion à la > "Vergleiche das eigene Objekt mit einem (per Referenz oder Pointer) > übergebenem anderen" ist leicht geschrieben. Hm wäre eine Idee. Ich hätte das lieber getrennt. Die "Oberklasse" soll auch noch andere Sachen können, unteranderen die Instanzen der Grundklassen verwalten. Ableiten macht irgendwie kein Sinn, da keine Methode der Hauptklasse in den Unterklassen gebraucht wird. D.h. kein überladen etc.
Bernd K. schrieb: > Wenn Du verschiedene Hunde hast (normale, welche die sprechen können und > sogar Hunde die fliegen können) dann erben die alle von der Basisklasse > Hund (weil bellen und beißen können sie alle). Und das einzige Pferd in > Deinem Zoo und der Hund erben beide von Vierbeiner. > > Der Dompteur jedoch der die Hunde trainiert hat kaum was mit diesen > gemeinsam. Außer vielleicht die Grundfunktionen aus der Klasse > Säugetier, davon sind auch die Vierbeiner abgeleitet. > > Nur nicht der Hundezwinger, der ist aus Metall und somit ganz was > anderes, der ist komplett separat, eventuell ist er aber entfernt mit > dem Pferdestall verwandt. Sowas weis ich auch ... Ich habe aber nicht verschiede Tiere sondern immer die gleichen und das was die Oberklasse sein soll, ist kein Vierbeiner sondern ein Auto.
Klasse schrieb: > Ich habe aber nicht verschiede Tiere sondern > immer die gleichen und das was die Oberklasse sein soll, ist kein > Vierbeiner sondern ein Auto Du hast Ponys, und du hast einen Ponnyhof. Der Ponyhof verwaltet die Ponys, er ist aber kein Pony, und auch die Ponys haben nichts gemein mit dem Ponyhof. Bei Vergleichen schreibt man aber üblicherweise
1 | if (Pony1 > Pony2) ... |
und das erfordert, daß die überladenen Vergleichsoperatoren Teil der Klasse Pony sind. Oliver
:
Bearbeitet durch User
Klasse schrieb: > Ich habe aber nicht verschiede Tiere sondern immer die gleichen und das was > die Oberklasse sein soll, ist kein Vierbeiner sondern ein Auto. Na also, dann ist die Sache doch klar. Klassenvererbung setzt eine "ist-ein"-Beziehung um. Ein Tier ist kein Auto, also wird es auch nicht davon abgeleitet.
Beim Vererben sollte man nicht in die Falle tappen, die ganze Welt in eine Klassenhierarchie zwängen zu wollen. OO ist dazu da, das Programm zu strukturieren und nicht die reale Welt. Im Haushaltsabrechnungsprogramm ist es vielleicht sinnvoll, einfach die Klassen Hund und Auto von MonthlyExpense abzuleiten. Stattdessen erstmal eine Klassenstruktur zu bauen, die das Reich der Säugetiere und der Fortbewegungsmittel (Fahrzeug<--4rädrig<--Auto<--Kompaktklasse<--Opel Kadett E<--13N) abbildet, ist völliger Quatsch.
Rolf Magnus schrieb: > Klassenvererbung setzt eine > "ist-ein"-Beziehung um. Ich kann es mir nicht verkneifen: ist ein Kreis eine Ellipse?
lalala schrieb: > Rolf Magnus schrieb: >> Klassenvererbung setzt eine >> "ist-ein"-Beziehung um. > > Ich kann es mir nicht verkneifen: ist ein Kreis eine Ellipse? :-) Das schlägt in die Kerbe vom TOM. Kumt drauf an. Der springende Punkt ist, dass eine Klassenhierrchie nicht etwas absolut sinnvolles ist. Je nach Programm, je nach Aufgabenstellung kann und wird eine Klassenhierarchie anders aussehen, selbst wenn es nach dem ersten Anschein sich eigentlich um dasselbe handelt. Und ja. Es gibt auch Grenzfälle und Sonderfälle, wie das Kreis-Ellipsen Problem. Oder auch Rechteck-Quadrat. Je nachdem, worum es im Programm geht, wird man die anders aufziehen. Aber mit der Daumenregel dqs eine 'ist-ein' Beziehung auf eine Ableitung hinweist, während eine 'hat-ein' Beziehung auf ein Membership hinweist, fährt man in den meisten Fällen erst mal nicht schlecht.
Karl Heinz schrieb: > Und ja. Es gibt auch Grenzfälle und Sonderfälle, wie das Kreis-Ellipsen > Problem. Oder auch Rechteck-Quadrat. Das sind doch alles theoretische erfindungen von Menschen, also kann man sie veralbemeinern; Als n-Dimensionale NURBS. Man leitet Kreise, Elipsen und Rechtecke vob NURBS ab, und gibt ihnen einen Konstruktor, der eine NURB nimmt. Dieser prüft, ob die NURB einwm Kreis, etc. entspricht, und wirft andernfalls eine Exception. Schon kann man aus Kreisen Elipsen und aus Elipsen Kreise machen, wenn es sich bei der NURB um beides handelt, und man muss sich nichtmehr darüber den Kopf zerbrechen, ob ein Kreis eine Elipse ist, das weiss die Elipse ja selber am besten. Also bei Kreis/Elipse Problehmen einfach veralgemeinern und die Gemeinsame Basis nutzen.
Daniel A. schrieb: > Dieser prüft, ob die NURB einwm Kreis, etc. entspricht, und > wirft andernfalls eine Exception. Nein, das ist Murks. Umgekehrt wird ein Schuh draus: Der Kreis nimmt Position und Radius im Konstruktor und erzeugt sein NURB daraus. Alle anderen Methoden sind von der NURB-Klasse geerbt.
Klasse schrieb: > Hm wäre eine Idee. Ich hätte das lieber getrennt. Die "Oberklasse" soll > auch noch andere Sachen können, unteranderen die Instanzen der > Grundklassen verwalten. Diese Verwaltung kann, muss aber nicht in einer eigenen Klasse geschehen. Es gibt ja auch noch andere Datenstrukturen als Klassen. Und je nach Programmiersprache gibt es auch auszuführenden Code außerhalb von Klassen, z.B. in C++. > Ableiten macht irgendwie kein Sinn, da keine Methode der Hauptklasse in > den Unterklassen gebraucht wird. D.h. kein überladen etc. Wenn es denn unbedingt eine eigene Klasse sein muss, dann kann diese einen Container oder etwas dergleichen beinhalten, welcher die (Referenzen auf die) zu verwaltenden Objekte enthält. Wenn Du verstehen möchtest, welche Beziehungen Klassen untereinander haben können, kannst Du unter anderem hier nachlesen: https://en.wikipedia.org/wiki/Class_diagram#Relationships
:
Bearbeitet durch User
Bernd K. schrieb: > Daniel A. schrieb: >> Dieser prüft, ob die NURB einwm Kreis, etc. entspricht, und >> wirft andernfalls eine Exception. > > Nein, das ist Murks. Umgekehrt wird ein Schuh draus: Der Kreis nimmt > Position und Radius im Konstruktor und erzeugt sein NURB daraus. Das schliest sich doch nicht aus, mit beiden konstruktoren kann man aber sowas machen:
1 | Elipse e(Circle( |
2 | Vector<3>(1,2,3) // position |
3 | + Matrix<3>.withRotation(10,90,270) // Rotation |
4 | , 20 // Radius |
5 | ));
|
Der Kreis wird implizit zur NURB gekastet, jede NURB könnte ein Kreis
sein, was sollte daran murks sein?
> Alle anderen Methoden sind von der NURB-Klasse geerbt.
Und die hat dann methoden, mit denen sie zum Kreis wird?!? operator
Circle(), würde sogar funktionieten...
Aber villeicht ist ein Kreis keine NURB, sondern ein GeometryObject, und
dieses hat eine NURB, statt eine zu sein?
lalala schrieb: > Rolf Magnus schrieb: >> Klassenvererbung setzt eine >> "ist-ein"-Beziehung um. > > Ich kann es mir nicht verkneifen: ist ein Kreis eine Ellipse? Ah ja, das Problem :-) Mathematisch gesehen lautet die Antwort natürlich ja. Bei der Umsetzung in Software ist es dann nicht mehr ganz so einfach. http://en.wikipedia.org/wiki/Circle-ellipse_problem
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.