Vererbung crc8 Tabelle

Peter II schrieb:

> Das macht doch wenig sinn,


Eben.
Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN' 
Beziehung gibt.

Ein PKW ist ein Auto. Ein LKW ist ein Auto. Ein Auto ist ein 
Kraftfahrzeug. Ein Motorrad ist ein Kraftfahrzeug.
Das alles sind Beispiele, in denen eine 'IST EIN' Beziehung 
offensichtlich ist.

Aber:
Eine UART ist ein CRC8 Gerät?
Das würde ich mal ganz stark in Zweifel ziehen.

Eine UART ist ein Kommunikationsgerät. Es verwendet vielleicht eine 
CRC8. Genauso wie so manch anderes Kommunikationsgerät. Aber deswegen 
ist eine UART kein CRC8 Gerät.

-> Vererbung ist hier sehr wahrscheinlich das falsche Stilmittel.

Alex schrieb:
> Ok Danke.
> Ja ist in der Statemaschiene einfacher zu handhaben.

Dann kann man immer noch den CRC Teil in einen CRC-Status-Teil und einen 
CRC-Maschinerie Teil zerlegen.
Jedes verwendende Objekt hat seinen eigenen Running-CRC Status. Aber es 
gibt nur eine einzige CRC-Maschinerie (in der dann auch die Tabelle 
liegt), die diesen CRC Status je nach Input auf den jeweils neuesten 
Stand bringt.

Man kann natürlich auch (in diesem Fall) eine CRC Klasse machen, die im 
Prinzip genau diesen Status enthält, und deren Objekte sich alle die 
konstante CRC-Basistabelle als einen static Member teilen. Im Endeffekt 
läuft es aufs gleiche raus, nur hat man 1 Klasse weniger.

Nichts desto trotz:
Eine UART IST KEIN CRC Objekt.
Es enthält vielleicht eines, so wie ein Auto einen Motor hat. Aber 
genausowenig wie ein Auto ein Motor IST, genausowenig ist eine UART eine 
CRC.


Als Faustregel

IST EIN
********

1

class A : public B

2

{

3

  ...

4

};

HAT EIN
*******

1

class A

2

{

3

  ...

4

5

  B memberB_;

6

};

Als erster Anlaufpunkt ist eine derartige Unterscheidung, die sich aus 
dem Alltagszusammenhang ergibt ("ist ein" versus "hat ein") meistens 
eine gute Richtlinie. Ob man dann im 'hat ein' Fall einen Member als 
Objekt hat, oder ob es dort eine Referenz oder einen Pointer auf eine 
einzige zentrale Instanz gibt (weil es in einer Firma zb nur eine 
einzige Warenausgabe gibt, d.h. die Firma hat nur 1 Warenausgabe-Objekt 
aber alle einzelnen Abteilungen enthalten Referenzen darauf), muss man 
im Einzelfall entscheiden.

Alex schrieb:
> Dann hab ich mich wohl falsch ausgedrückt...
>
> Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt. I2C_COM
> bekommt die Klasse I2C und CRC8 vererbt.

Bist du sicher dass du das Konzept der Vererbung bei OOP verstanden 
hast?

Alex schrieb:
> Dann hab ich mich wohl falsch ausgedrückt...
>
> Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt.

Also Mehrfachvererbung?

Kann man machen, muss man aber nicht machen.
Hier wär mir der Zusammenhang zwischen den geerbten Klassen etwas zu 
lasch. Ich würde der Uart1 einen Member einer CRC Klasse verpassen, 
wobei sich alle CRC Objekte die Tabelle als statischen Member teilen.

Alex schrieb:
> Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt.

???
"Der State" lese ich zumindest so, daß damit ein Zustand irgendeiner 
State-machine gemeint ist. Ein solcher Zustand hat in meinen State 
Machines normalerweise einen byte oder integer Wert und vieleicht noch 
einen String als Namen, mehr nicht.

Bei dir IST ein solcher Zustand ein serielle Schnittstelle?
Bei dir IST dieser Zustand zusätzlich auch ein CRC8 Generator?

Mehrfachvererbung ist meist das Ergebnis schlechten Designs.
Immer KISS (keep ist simple and stupid) beachten.

zb, dass du nur mit Verrenkungen gleichzeitig CRC Betrieb auf der Sende 
und Empfangsstufe laufen lassen kannst.

Wenn etwas eigentlich einfaches nur mit Verrenkungen möglich ist, dann 
ist das meiner Erfahrung nach ein Indiz dafür, dass in der 
Klassenhierarchie etwas nicht stimmt.

Aber vielleicht brauchst du ja auch nicht die Fähigkeit gleichzeitig mit 
CRC Überwachung senden und empfangen zu können.

Fred schrieb:
> Karl Heinz schrieb:
>> Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN'
>> Beziehung gibt.
>
> Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse.

Ok.
Ich bein eigentlich schon davon ausgegangen, dass es um die prinzipielle 
Fragestellung 'Vererbung' oder 'Member Inclusion' geht. Die Frage, 
inwiefern sich dann einzelne Objekte durch die Parametrierung der 
Objekte unterscheiden hab ich mal aussen vor gelassen. In diesem Sinne 
gilt ja auch, dass ein Audi ein Auto ist, man aber sehr wahrscheinlich 
keine Klasse 'Audi' von 'PKW' herleiten wird.

Karl Heinz schrieb:
> Fred schrieb:
>> Karl Heinz schrieb:
>>> Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN'
>>> Beziehung gibt.
>>
>> Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse.
>
> Ok.
> Ich bein eigentlich schon davon ausgegangen, dass es um die prinzipielle
> Fragestellung 'Vererbung' oder 'Member Inclusion' geht.

Das Kreis-Ellipse Problem ist ein klassisches Beispiel um gegen OOP zu 
hetzen. Denn dort funktioniert der naive Ansatz "IST EIN" ganz schlecht 
und zwar in beide Richtungen. Wobei sich das ganz schnell auflöst wenn 
man eben nicht davon ausgeht dass ein Kreis eine Ellipse oder umgekehrt 
ist. IMO ist diese Annahme überhaupt nicht zwingend. Die Stimmung gegen 
OOP und dieses Beispiel, kommt aus recht prominenten Kreisen auch 
innerhalb der FSF, glaube sogar vom großen Stallman persönlich.

gruß cyblord

cyblord ---- schrieb:

> hetzen. Denn dort funktioniert der naive Ansatz "IST EIN" ganz schlecht
> und zwar in beide Richtungen. Wobei sich das ganz schnell auflöst wenn
> man eben nicht davon ausgeht dass ein Kreis eine Ellipse oder umgekehrt
> ist. IMO ist diese Annahme überhaupt nicht zwingend.


Wobei es in der Informatik sowieso nur ganz wenige 100% Regeln gibt. 
Genau deshalb hab ich ja auch von einer Faustregel gesprochen.
Wenn Informatik so einfach wäre, dass man nur 30 Regeln ungefragt und 
ohne nachdenken zu müssen anwendet und man dann automatisch ein super 
Programm bekommt, dann bräuchte man kein Informatik-Studium und auch 
keine Erfahrung. Dann könnte das jede Hausfrau (keine Beleidigung 
beabsichtigt).

Wer immerwährende Grundsätze sucht, die er unüberlegt anwenden kann, der 
muss zu den Religionen gehen. Dort ist das sogar ein wesentliches 
Element, dass man nicht näher die Regeln hinterfragen und gegebenenfalls 
anpassen bzw. verletzen darf.

Alex schrieb:
> Ist ok.
> Der Aufwand die Statemaschiene und ihre Möglichkeiten zu erklären ist
> mir jetzt zu groß.
> Aber es ist nicht einfach nur eine Zeile Code. Sondern so ~600 min
> schätz ich mal.

Ich verstehs immer noch nicht.
Wenn der ursprüngliche Klassenansatz einigermassen Sinn machte, dann ist 
es normalerweise einfach, die Klassenhierarchie etwas anzupassen, ohne 
dass es exorbitant viele tatsächliche Codeänderungen gibt.

Aber seis drum. Unter deinen Voraussetzungen sehe ich nicht wirklich da 
jetzt ein großes Problem (wohl aber eines, das eines Tages kommen 
könnte, wenn sich die Anforderungen an die Klasse verändern).

Wie auch immer. Es scheint wohl so zu sein, dass sich deine 
ursprüngliche Fragestellung damit lösen lässt, das du die CRC Tabelle 
als static Member in der CRC Klasse gestaltest. Das wiederrum ist etwas, 
was auf jeden Fall sinnvoll ist, egal wie der restliche Aufbau aussieht.

Fred schrieb:
> Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse.

Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was 
verpasst?

Fred schrieb:
> cyblord ---- schrieb:
>> Das Kreis-Ellipse Problem ist ein klassisches Beispiel um gegen OOP zu
>> hetzen.
>
> Keineswegs. Es ist ein klassisches Beispiel, um zu zeigen, daß
> objektorientierte Modellierung sich nicht an Echtwelt-Objekten
> festklammern soll, sondern daß sie lediglich ein Ausdrucksmittel ist, um
> gewisse Vorteile im Code zu erzielen. Beispielsweise Dispatching oder
> gemeinsame Nutzung von Codestücken.

Da hast du recht. Nur wird es von gewissen Kreise gerne zum hetzen 
benutzt. Lehrreich ist es auf jeden Fall.

> Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was
> verpasst?

Wenn du als Klasse einen Kreis nimmst, mit einem Feld, dem Radius, und 
dann eine Klasse Ellipse machst, die vom Kreis erbt, bringt ihr das 
Radius-Feld gar nichts. Weil eine Ellipse Breite und Höhe braucht. 
Andersrum ebenfalls.  Somit klappt hier der OOP-Ansatz nicht. Obwohl, 
rein geometrisch, der Kreis nur eine Sonderform der Ellipse ist.

Michael Reinelt schrieb:
> Fred schrieb:
>> Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse.
>
> Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was
> verpasst?


Er stört sich daran, dass einem blindes Gehorchen von Richtlinien, die 
explizit als 'Faustregeln' und 'erste Näherungen' bezeichnet wurden, zu 
...

1

class Ellipse : public Geometry

2

{

3

  ...

4

};

5

6

class Circle : public Ellipse

7

{

8

  ...

9

};

... führt.

Wer das schon mal in einem Geometrie Programm probiert hat, wird 
festgestellt haben, dass er sich damit eine Menge Probleme aufhalst. 
Denn je nach Verändern der Parameter 'Länge der Halbachsen' wird dann 
plötzlich aus dem einen Objekttyp ein anderer Objekttyp.
Genauso wie zb ein Quadrat nicht wirklich als Sonderform eines Rechtecks 
in der Klassenhierarchie modelliert wird, obwohl umgangssprachlich ein 
Quadrat eine Sonderform eines Rechtecks IST.

Wie er sagt: "wer naiv ..."
Und genau da liegt der springende Punkt. Wer naiv seinem Guru hinterher 
läuft und seine Regeln ohne zu hinterfragen akzeptiert, der ist Priester 
und kein Informatiker.
Das bedeutet aber noch lange nicht, dass diese Faustregeln generell zu 
nichts nütze wären. Man muss einfach nur akzeptieren, dass sie einen in 
manchen Fällen auch in die Irre führen. 'One size fits all' funktioniert 
bei Baseballkappen, aber nicht in der Programmentwicklung. Und das ist 
gut so, denn sonst wär ich arbeitslos. :-)

Karl Heinz schrieb:

> Wie er sagt: "wer naiv ..."
> Und genau da liegt der springende Punkt. Wer naiv seinem Guru hinterher
> läuft und seine Regeln ohne zu hinterfragen akzeptiert, der ist Priester
> und kein INformatiker.

Daher heißen die ja auch "FSF-Jünger".

Übrigens, KHB du wirkst ein bisschen gereizt. Ich denke jedem hier ist 
klar, was du meinst. Ich habe nur nach der "provokanten Frage" von Fred, 
angefügt dass diese oftmals zum hetzen missbraucht wird. Mehr wurde 
nicht gesagt. Also komm mal wieder runter...

cyblord ---- schrieb:

>> Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was
>> verpasst?
>
> Wenn du als Klasse einen Kreis nimmst, mit einem Feld, dem Radius, und
> dann eine Klasse Ellipse machst, die vom Kreis erbt, bringt ihr das
> Radius-Feld gar nichts.
Logisch weil eine Ellipse auch nicht eine Sonderform des Kreises ist, 
sondern umgekehrt.

> Andersrum ebenfalls.  Somit klappt hier der OOP-Ansatz nicht. Obwohl,
> rein geometrisch, der Kreis nur eine Sonderform der Ellipse ist.
 Warum nicht? (vielleicht dämliche Frage, aber ich bin in OOP nicht so 
tief drinnen). Ich müsste ja nur die beiden Achsen "verstecken" ein 
neues Attribut "Radius" (oder von mir aus Druchmesser) einführen und 
Breite/Höhe auf den Radius setzen. Dann kann ich alle möglichen und 
unmöglichen Berechnungen der Ellipse 1:1 für den Kreis durchführen (auch 
wenn das performancemäßig nicht ganz optimal sein wird)

cyblord ---- schrieb:

> Übrigens, KHB du wirkst ein bisschen gereizt. Ich denke jedem hier ist
> klar, was du meinst.

Dann frage ich mich, was dieser Zwischenruf überhaupt sollte.
Wenn ich diese Regeln als unumstössliche Wahrheiten dargestellt hätte, 
wäre es ok gewesen. Aber genau das hab ich nicht getan. Ganz im 
Gegenteil hatte ich sehr darauf geachtet, das als Leitlinie 
darzustellen.
Aber egal was ich sage, immer kommt jemand daher, der einem das Wort im 
Mund umdreht.

Michael Reinelt schrieb:

>> Andersrum ebenfalls.  Somit klappt hier der OOP-Ansatz nicht. Obwohl,
>> rein geometrisch, der Kreis nur eine Sonderform der Ellipse ist.
>  Warum nicht? (vielleicht dämliche Frage, aber ich bin in OOP nicht so
> tief drinnen).


Ist ok.


Machen kannst du es. Das Problem kommt, wenn du dann mit den Objekten 
auch Operationen machen willst.
Zum Beispiel die Operation "Skalieren".
Was bei anderen Objekttypen problemlos klappt, wird hier zu einem 
Problem. Durch eine Skalieroperation wird aus einem Kreis eine Ellipse. 
Bzw. auch umgekehrt kann mit der richtigen Skalieroperation aus einer 
Ellipse ein Kreis werden.

Wie aber gestaltest du das als Memberfunktion?
Und zwar möglichst so, dass du in der darunter liegenden Basisklasse 
(Geometrie-Dings) eine virtuelle Scale Funktion hast von der alle 
abgeleiteten Klassen erben?

Karl Heinz schrieb:
> Was bei anderen Objekttypen problemlos klappt, wird hier zu einem
> Problem. Durch eine Skalieroperation wird aus einem Kreis eine Ellipse.

Nicht wenn du für einen Kreis die Skalierfunktion überschreibst daß sie 
beie Achsen gleichzeitig skalierst.
Genauso kannst du die Setter überschreiben, daß sie beim setzen von r1 
auch r2 auf den gleichen Wert setzen.

Es ist wie du richtig sagst, man muss eben das Hirn benutzen.

Karl Heinz schrieb:
[Kreis <=> Ellips]
> Machen kannst du es. Das Problem kommt, wenn du dann mit den Objekten
> auch Operationen machen willst.
> Zum Beispiel die Operation "Skalieren".

Guter Einwand! Extrem guter Einwand! Muss ich mir merken!

Erinnert mich frappant an meine CAD-Zeit. Als der Kunde Kreise 
schräggestellt haben wollte. Aber mit der Einschränkung, dass es Kreise 
bleiben müssten. Weil seine CNC-Maschine (Drahterodieren) nur Kreise 
könne...

Ach, was bin ich froh dass diese zeit vorbei ist :-)

Karl Heinz schrieb:
> eine virtuelle Scale Funktion

Eben die ist virtuell, weil sie bei unterschiedlichen abgeleiteten 
Klassen unterschiedlich ausgeprägt sein kann.
Alternativ ist sie nicht virtuell, weil für viele abgeleitete Klassen 
genügend, aber bestimmte müssen sie trotzdem überschreiben.

Beispiel Fahrzeug, abgeleitet Auto und Motorrad. Sowohl bremsen, als 
auch kuppeln als auch Gas geben ist bei beiden völlig unterschiedlich 
implementiert.

Udo Schmitt schrieb:
> Karl Heinz schrieb:
>> Was bei anderen Objekttypen problemlos klappt, wird hier zu einem
>> Problem. Durch eine Skalieroperation wird aus einem Kreis eine Ellipse.
>
> Nicht wenn du für einen Kreis die Skalierfunktion überschreibst daß sie
> beie Achsen gleichzeitig skalierst.
> Genauso kannst du die Setter überschreiben, daß sie beim setzen von r1
> auch r2 auf den gleichen Wert setzen.
>
> Es ist wie du richtig sagst, man muss eben das Hirn benutzen.

Natürlich geht das, aber wenn du am Ende ALLES überschreiben musst, und 
für alles ne Extrawurst brauchst, wozu dann noch die Vererbung. Dann 
sparst du keine Zeile Code und das ganze ist ad absurdum geführt. Das 
ist der Punkt hinter dieser Sache.

Aber nochmal, der Einwand war nicht gegen deinen Post gerichtet, 
Karl-Heinz. Es war nur eine Info am Rande.

gruß cyblord

cyblord ---- schrieb:
> Natürlich geht das, aber wenn du am Ende ALLES überschreiben musst, und
> für alles ne Extrawurst brauchst, wozu dann noch die Vererbung. Dann
> sparst du keine Zeile Code und das ganze ist ad absurdum geführt.

Das ist so nicht richtig. Beispiel Fahrzeug. Du hast entweder ein 
Motorrad oder ein Auto instanziiert. Es macht trotzdem Sinn beide vom 
Fahrzeug abzuleiten (oder ein Interface Fahrzeug zu benutzen) denn dann 
kannst du beide als Fahrzeug an eine Methode fahren einer Klasse Fahrer 
übergeben, und die Methode benutzt nur Gas geben, Bremsen und lenken, 
ohne sich um die Implementirung scheren zu müssen.
OO ist deutlich mehr als nur Code Zeilen sparen.

Udo Schmitt schrieb:

> Beispiel Fahrzeug, abgeleitet Auto und Motorrad. Sowohl bremsen, als
> auch kuppeln als auch Gas geben ist bei beiden völlig unterschiedlich
> implementiert.

Schon richtig.
Aber nach dem Bremsen ist ein Motorrad immer noch ein Motorrad.

> Nicht wenn du für einen Kreis die Skalierfunktion überschreibst
> daß sie beie Achsen gleichzeitig skalierst.

Ich hatte das eher so gemeint, dass man einen Kreis nur in einer 
Richtung skaliert :-) Eine Operation, die ein CAD ja können muss.

Befüllst du aber eine Liste mit Objekten

1

   content.add( new Circle( point, radius ) );

und wendest du auf die selektierten Objekte die Operation an

1

  foreach( Geometry* obj, selectedContent )

2

    obj->scale( x_factor, 0.0 );

dann hast du den 'unschönen' Zustand, einen Kreis in der Datenbasis zu 
haben, der in Wirklichkeit gar kein Kreis mehr ist.

Udo, ich brauche keine Belehrung über die Grundlagen von OOP. Ich habe 
bereits mein Info-Diplom.

Lies bitte hier nochmal genau nach, wenn du den Punkt nicht verstehst: 
http://de.wikipedia.org/wiki/Kreis-Ellipse-Problem

@Fred:
Du bringst es auf den Punkt!

Karl Heinz schrieb:
> Ich hatte das eher so gemeint, dass man einen Kreis nur in einer
> Richtung skaliert :-) Eine Operation, die ein CAD ja können muss.

Ok, zeigt wieder das Denken nimmt einem keiner ab :-)
Im gegenteil, je mächtiger das Tool (OOP) desto mehr unterschiedliche 
Wege führen nach Rom, und nicht alle sind immer sinnvoll.

Karl Heinz schrieb:
> Schon richtig.
> Aber nach dem Bremsen ist ein Motorrad immer noch ein Motorrad.

Wie gesagt, man müsste dann halt alle Operationen so überschreiben daß 
es nicht dazu kommen kann daß r1 und r2 unterschiedlich sind.
Ob das dann noch eine gute und sinnvolle Implementierung ist, ist eine 
andere Frage...

> Nicht wenn du für einen Kreis die Skalierfunktion überschreibst
> daß sie beie Achsen gleichzeitig skalierst.

Im Wiki-Artikel wird darauf ebenfalls eingegangen. Das ist nicht erlaubt 
bzw. nicht zu empfehlen. Weil es sich im Verhalten ggü. einer Ellipse 
extrem unterscheidet und das so vom Nutzer nicht vorrausgesehen werden 
kann.


Siehe auch:
http://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip

cyblord ---- schrieb:
> @Fred:
> Du bringst es auf den Punkt!

Dabei bist jetzt du unentspannt:

cyblord ---- schrieb:
> Udo, ich brauche keine Belehrung über die Grundlagen von OOP. Ich habe
> bereits mein Info-Diplom.

Warum hast du dann alles auf Code Ersparnis reduziert?
Egal, wenns jetzt darum geht wer was für einen Abschluss hat bin ich 
raus :-)

cyblord ---- schrieb:
>> Nicht wenn du für einen Kreis die Skalierfunktion überschreibst
>> daß sie beie Achsen gleichzeitig skalierst.
>
> Im Wiki-Artikel wird darauf ebenfalls eingegangen. Das ist nicht erlaubt
> bzw. nicht zu empfehlen. Weil es sich im Verhalten ggü. einer Ellipse
> extrem unterscheidet und das so vom Nutzer nicht vorrausgesehen werden
> kann.

Yep.
Man könnte natürlich von einem menschlichen Benutzer verlangen, dass er 
zunächst den Sonderfall 'Kreis' in eine 'Ellipse' umwandelt und erst 
dann die Operation durchführt. Tut er das nicht, dann geht die Operation 
schief.

Allerdings, was ein menschlicher Benutzer, der vor dem Bildschirm sitzt, 
gerade noch akzeptiert ist eine Sache. Was man dann in einem 
Batchbetrieb macht, wenn 300 CAD-Zeichnungen durch einen Prozessor 
laufen ist eine andere Sache.

Letzten Endes muss man immer im Einzelfall anhand der konkreten 
Situation entscheiden, was man tut.

Udo Schmitt schrieb:

> Warum hast du dann alles auf Code Ersparnis reduziert?
Hab ich nicht. Es geht nicht um die Ersparnis selbst. Sondern um 
Extrawürste für spezielle Unterobjekte, was man eben so nicht haben 
will. z.B. dass sich die Breite ändern, wenn ich eine Methode zum ändern 
der Höhe aufrufe.
Wenn du Vererbung betreibst und keinen Code einsparen kannst, dann ist 
das ein sicheres Zeichen dass was schief läuft. Es ist ein Symptom.

> Egal, wenns jetzt darum geht wer was für einen Abschluss hat bin ich
> raus :-)
Darum gehts nicht, aber wir brauchen doch bei einem bekannen 
Informatik-Problem nicht bei Adam und Eva anfangen zu diskutieren was 
Vererbung ist und wozu man sie braucht.

gruß cyblord

cyblord ---- schrieb:
> Wenn du Vererbung betreibst und keinen Code einsparen kannst, dann ist
> das ein sicheres Zeichen dass was schief läuft. Es ist ein Symptom.

Auch da kann ich jetzt nicht einfach zustimmen, du kannst immer noch den 
Code für eine Zeichenroutine einsparen, oder den Code um ein umfassendes 
Rechteck zu berechnen.
Und wir sind uns einig, daß man immer noch Brain2.0 benutzen muss und es 
dafür keinen Königsweg gibt und man manchmal dann statt Vererbung 
gleichwertige Klassen die aus einer Basisklasse erben nutzen sollte.

Und ich habe gelernt, daß das Rechteck/Quadrat Ellips/Kreis Problem ein 
vielfach akademisch diskutiertes Problem ist, das wusste ich noch nicht.

Udo Schmitt schrieb:
> Und ich habe gelernt, daß das Rechteck/Quadrat Ellips/Kreis Problem ein
> vielfach akademisch diskutiertes Problem ist, das wusste ich noch nicht.

Dem schließe ich mich an, danke!

Udo Schmitt schrieb:
> cyblord ---- schrieb:
>> Wenn du Vererbung betreibst und keinen Code einsparen kannst, dann ist
>> das ein sicheres Zeichen dass was schief läuft. Es ist ein Symptom.
>
> Auch da kann ich jetzt nicht einfach zustimmen, du kannst immer noch den
> Code für eine Zeichenroutine einsparen, oder den Code um ein umfassendes
> Rechteck zu berechnen.

Ach, da geht noch viel mehr.
Gerade beim Ellipsen-Kreis Problem ist das ja symptomatisch. Den Umfang 
eines Kreises zu berechnen ist trivial. Den Umfang einer Ellipse zu 
berechnen ist in geschlossener Form gar nicht möglich. Die dabei 
anfallenden Integrale sind formelmässig nicht lösbar und hab in der 
Mathematik zu einer ganzen Klasse geführt, die man 'elliptische 
Integrale' nennt. Selbiges mit der Fläche.
Unter anderem deshalb ist es ja so verführerisch eine Klasse Kreis von 
einer Klasse Ellipse herzuleiten um den Trivialfall vom allgmeinen Fall 
zu trennen.