Klassen Vererbung usw.

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.

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

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.

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

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