Das schreit nach einem Design Fehler und du verletzt somit das LSP.

Ich verletzte damit gerade deshalb nichts, weil ich keine "is-a" Beziehnung modellieren will. Ich will nur Tipparbeit sparen.

wenn es dir nur um die implementierung geht nimm private vererbung oder komposition

wenn es dir nur darum geht, dass z.B. alle deine klassen vom prinzip her gleich aufgebaut sind und auch alle gleiche namen haben sollen (also die methoden), bleibtdir denke ich mal nichts anderes übrig als das alls zu tippen

Ich habe eine Klasse B die das public Interface von A übernehmen soll, aber es soll keine implizite Konvertierung zwischen B* und A* stattfinden. Wie mache ich das?

Indem A und B vom gleichen Interface erben. B aber nicht von A.

doch das tust du, ansonsten würdest du eben nicht public erben wollen, denn genau das sagt öffentlich verbung ja aus -> is-a

Bitte ordentlich lesen. Ich habe Vererbung nicht mal erwähnt.

@nurf Dann habe ich das gleiche Problem wie vorher.

Skym0sh0 schrieb:

doch das tust du, ansonsten würdest du eben nicht public erben wollen, denn genau das sagt öffentlich verbung ja aus -> is-a

Bitte ordentlich lesen. Ich habe Vererbung nicht mal erwähnt.

indirekt schon, denn die beschriebene Konvertierung gibt es nur bei public-Vererbung. Skym0sh0 weiß das. Du anscheinend nicht.

@nurf Dann habe ich das gleiche Problem wie vorher.

Nope.

class base{};

class A:public base{};
class B:public base{};

class public_derivation: public base{};
class protected_derivation: protected base{};
class private_derivation: private base{};

int main()
{
  A *a;
  B *b;
  base *base_ptr;

  a = b;  // Nö
  b = a;  // Nö
  a = base_ptr;  // Nö
  b = base_ptr;  // Nö
  base_ptr = a;  // Ja
  base_ptr = b;  // Ja

  public_derivation *public_ptr;
  protected_derivation *protected_ptr;
  private_derivation *private_ptr;

  base_ptr = public_ptr;  // Ja
  base_ptr = protected_ptr;  // Nö
  base_ptr = private_ptr;  // Nö
}

indirekt schon, denn die beschriebene Konvertierung gibt es nur bei public-Vererbung. Skym0sh0 weiß das. Du anscheinend nicht.

Also wenn ich nach etwas mit Eigenschaft A und B Frage und mit jemand etwas mit Eigenschaft A gibt, habe ich genau danach gefragt. Gut zu wissen. Logic(!)

SeppJ schrieb:

Nope.

Doch. B braucht so immer noch einen virtuellen Destruktor. (Den du irgendwie vergessen hast..)

Also noch mal: B soll sich verhalten wie eine eigene, normale Klasse. Ohne irgendwelche impliziten Konvertierungen oder sonst was. Es geht nur darum Tipparbeit zu sparen. Das ist das einzige was ich will. Es sollen keine tiefgründigen Abhängigkeiten modelliert werden.

Es geht nur darum Tipparbeit zu sparen.

Copy&Paste

Und das ist ernst gemeint.

SeppJ schrieb:

indirekt schon, denn die beschriebene Konvertierung gibt es nur bei public-Vererbung. Skym0sh0 weiß das. Du anscheinend nicht.

Also wenn ich nach etwas mit Eigenschaft A und B Frage und mit jemand etwas mit Eigenschaft A gibt, habe ich genau danach gefragt. Gut zu wissen. Logic(!)

Falls das Ironie sein soll: Fail? Dein B (es gibt implizite Konvertierung) ist äquivalent zu A (public Vererbung wurde genutzt). Daher ist es vollkommen ausreichend, von A oder B zu sprechen.

SeppJ schrieb:

Nope.

Doch.

Ähh, nein? Zeile 16,17 in meinem Beispiel.

Virtueller Destruktor: Wenn du keine Pointerkonvertierungen haben willst, ist wohl davon auszugehen, dass niemals im Programm base* vorkommen werden. Selbst wenn: Dann mach eben einen virtuellen Destruktor. Was spricht dagegen? Dadurch werden A* und B* auch nicht kompatibel.

Also noch mal: B soll sich verhalten wie eine eigene, normale Klasse. Ohne irgendwelche impliziten Konvertierungen oder sonst was. Es geht nur darum Tipparbeit zu sparen. Das ist das einzige was ich will. Es sollen keine tiefgründigen Abhängigkeiten modelliert werden.

Und inwiefern wird dies nicht durch private-Vererbung, gemeinsame Basisklasse oder Komposition erfüllt? Irgendeine Art von Modellierungsabhängigkeit muss ja bestehen, sonst können die Klassen nicht den gleichen Code benutzen. Als kleinster Nenner muss also mindestens eine "ist in der gleichen Art implementiert"-Beziehung vorliegen.

Falls das Ironie sein soll: Fail? Dein B (es gibt implizite Konvertierung) ist äquivalent zu A (public Vererbung wurde genutzt).

Nur so als Anmerkung: Er wollte doch gerade keine implizite Konvertierung?

Das Problem dabei ist halt, dass Änderungen sich nicht überall gleich auswirken.
Könnte man so etwas nicht mal in die Sprache bauen?

Gleiches Interface für mehrere Klassen ist bereits eingebaut über Vererbung.

Du hast im Grunde nur 3 Möglichkeiten.

1. Du schaffst dir eine Basisklasse und erbst die anderen Klassen davon, die geerbten Klassen sind untereinander nicht kompatibel. Das ist die sichere und sauber Methode.

2. Du fängst an Macros zu bauen die die Funktion enthalten. Das würde erreichen was du willst. Ich würde dir aber davon abraten, da Macros fehleranfällig sind und der Code damit fehleranfällig wird.

3. Das von Shade vorgeschlagene Copy n Paste, da es sich ja um 2 vollkommen getrennte Klassen handeln soll.

1. Du schaffst dir eine Basisklasse und erbst die anderen Klassen davon, die geerbten Klassen sind untereinander nicht kompatibel. Das ist die sichere und sauber Methode.

2. Du fängst an Macros zu bauen die die Funktion enthalten. Das würde erreichen was du willst. Ich würde dir aber davon abraten, da Macros fehleranfällig sind und der Code damit fehleranfällig wird.

3. Das von Shade vorgeschlagene Copy n Paste, da es sich ja um 2 vollkommen getrennte Klassen handeln soll.

1. finde ich nicht so sauber. sauebr fände ichs, wenn man wirklich nur allen methoden gleiche namen gibt aber keinerlei beziehung zwischen den klassen hat. und das geht leider nur mit der guttenberg taktik

2. da stimme ich dir voll und ganz zu

3. und hier auch

Das Problem dabei ist halt, dass Änderungen sich nicht überall gleich auswirken.
Könnte man so etwas nicht mal in die Sprache bauen?

Dein Problem ist nicht die Sprache, sondern deine Modellierung.

PS:
man kann sich Code automatisch generieren lassen wenn man wirklich zu tippfaul ist. Aber im ernst: tipparbeit beim Programmieren ist vielleicht 0,00000000000001% der Zeit. Also wayne?

SeppJ schrieb:

Falls das Ironie sein soll: Fail? Dein B (es gibt implizite Konvertierung) ist äquivalent zu A (public Vererbung wurde genutzt).

Nur so als Anmerkung: Er wollte doch gerade keine implizite Konvertierung?

Es ging darum, dass er gemeint hat, dass eine implizite Konvertierungsmöglichkeit zwischen Zeigern auf nutzerdefinierte Datentypen nicht äquivalent wäre zu einer public-Vererbungsbeziehung. Aber die Diskussion ist so langsam ziemlich meta, wie man an dieser einfachen Zusammenfassung merkt.