Forum: PC-Programmierung C++ Mit Interfaces um sich schmeißen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Milhouse van Hauten (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hallo mal wieder,

zunächst entschuldigt den flappsig formulierten Betreff. Wahrscheinlich 
gibt es für mein Anliegen einen mir unbekannten Fachausdruck.

Als Beispiel folgendes Szenario:
Ich habe einen Pool aus Objekten, die in 3 Kategorien passen:
A) Manche sollen IMMER Methode A enthalten und implementieren
B) Manche sollen IMMER Methode B enthalten und implementieren
C) Manche sollen IMMER Methode A und B  enthalten und implementieren

Alle drei Fälle sollen in Listen gehalten werden. D.h. ich würde 
Interfaces A, B, C definieren. Das wiederum würde bedeuten, Objekte der 
Kategorie C würden von zwei Interfaces erben.

Wenn es jetzt mehr Kategorien/Interfaces gibt, würde mein Anatz zu einem 
Wust an vererbten Interfaces auf die selbe Klasse führen.
Das fühlt sich nicht an, als ob das im Sinne des Erfinders ist?


viele Grüße!

von D. I. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Milhouse van Hauten schrieb:
> Wenn es jetzt mehr Kategorien/Interfaces gibt, würde mein Anatz zu einem
> Wust an vererbten Interfaces auf die selbe Klasse führen.
> Das fühlt sich nicht an, als ob das im Sinne des Erfinders ist?

https://en.wikipedia.org/wiki/Interface_segregation_principle

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Milhouse van Hauten schrieb:
> Wenn es jetzt mehr Kategorien/Interfaces gibt, würde mein Anatz zu einem
> Wust an vererbten Interfaces auf die selbe Klasse führen.
> Das fühlt sich nicht an, als ob das im Sinne des Erfinders ist?

Da es "den" Erfinder dazu nicht gibt, ist dem das völlig egal. Wenn du 
da jetzt mit hunderten Interfaces hantierst, ist eventuell dein ganzer 
Ansatz Murks, aber ansonsten ist diese Aufteilung im Sinne des 
Erfinders...

Was hast du denn für Bedenken?

Oliver

von Milhouse van Hauten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Aus den beiden Antworten und dem gelinkten Wikieintrag lese ich, dass 
ich auf dem richtigen Weg bin. (?)
Die "Jobs" bei währen z.B. einmal Methoden zum 
Serialisieren/Deserialisieren und einmal um die eigentliche interne 
Logik anlaufen zu lassen.

Meine Frage rührt daher, dass ja C# z.B. keine Mehrfachvererbung 
zulässt. DA könnte ich also nicht eine Klasse von zwei Interfaces erben 
lassen.
D.h. es müsste einen anderen Weg geben.

Das soll nicht heißen, dass ich es nicht auch sinnvoll finde 
verschiedene Jobs auf verschiedene Interfaces auf zu teilen. Nur fehlt 
mir der Backround um sicher zu sein, dass ich das Richtige tue.

viele Grüße!

von D. I. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Milhouse van Hauten schrieb:
> Meine Frage rührt daher, dass ja C# z.B. keine Mehrfachvererbung
> zulässt. DA könnte ich also nicht eine Klasse von zwei Interfaces erben
> lassen.
> D.h. es müsste einen anderen Weg geben.

Natürlich geht das, allerdings verwechselst du die Begrifflichkeiten. 
Interfaces werden implementiert, nicht abgeleitet und das geht auch in 
C# in beliebiger Anzahl, nur ableiten geht nur von einer Klasse.
1
class UltraFatMonsterClassWhichInheritsFromOneBaseClassAndImplementsManyInterfacesAtOnce : UltraFatMonsterBaseClass, IPersister, ISerializer, IDeserializer, ICommunicator, IEnumerable, IStuffMaker {}

von J. F. (Firma: Père Lachaise) (rect)


Bewertung
0 lesenswert
nicht lesenswert
Was hindert dich daran es einfach mal auszuprobieren? Wenn es am Ende 
funktioniert hast du mehr davon als wenn du dir auf dem Weg darüber den 
Kopf zerbrichst wie es auch gehen könnte. Danach umbauen geht dann immer 
noch. Diese Vorgehensweise ist meist sinniger.

von Milhouse van Hauten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>>@ Autor: D. I. (grotesque)

Stimmt, geht auch in C# das eine Klasse mehrer Inetrfaces implementiert. 
War mir nicht bewusst. Musste ich eben nachschauen.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Da du in der Überschrift C++ schreibst, im Text aber C#, solltest du dir 
als erstes mal eine Meinung bilden, was du eigentlich willst.

Oliver

von D. I. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Da du in der Überschrift C++ schreibst, im Text aber C#, solltest du dir
> als erstes mal eine Meinung bilden, was du eigentlich willst.
>
> Oliver

Er hat verglichen und dabei Begriffe durcheinander geworfen, das sollte 
nur geradegerückt werden. In C++ bin ich nicht so fit, da gibt es doch 
meines Wissens keine dedizierten Interfaces, oder? Soweit ich mich 
erinnern kann, macht man dies doch mit abstrakten Klassen und 
virtual-only Methoden, da C++ ja Mehrfachvererbung beherrscht.

von Klops (Gast)


Bewertung
1 lesenswert
nicht lesenswert
D. I. schrieb:
> In C++ bin ich nicht so fit, da gibt es doch meines Wissens keine
> dedizierten Interfaces, oder?

Der Unterschied ist in C++ eher konzeptioneller Natur: Unter "Interface" 
verstehe ich eine Klasse mit rein virtuellen Methoden und ohne jegliche 
Implementierung, unter "abstrakte Klasse" eher eine Klasse mit 
irgendeinem konkreten Anteil (wobei, wie gesagt, in C++ technisch auch 
ein Interface eine abstrakte Klasse ist). U.a. in Java und C# gibt es 
dagegen Interfaces und "abstract class" als explizite, separate 
Sprachmittel.

von valvestino (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Milhouse van Hauten schrieb:
> Alle drei Fälle sollen in Listen gehalten werden. D.h. ich würde
> Interfaces A, B, C definieren. Das wiederum würde bedeuten, Objekte der
> Kategorie C würden von zwei Interfaces erben.

Warum willst Du 3 Interfaces definieren? Zwei reichen völlig. Die 
Klasse, die die Methoden A und B benötige, implementiert halt zwei 
Interfaces...

Grüße
Markus

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Milhouse van Hauten schrieb:

> Meine Frage rührt daher, dass ja C# z.B. keine Mehrfachvererbung
> zulässt.

Und das ist auch gut so. Mehrfachvererbung ist einfach Müll, der dem 
Grundansatz von OOP widerspricht.

> DA könnte ich also nicht eine Klasse von zwei Interfaces erben
> lassen.

Man kann überhaupt nicht von Interfaces erben, weder von einem noch von 
mehreren. Aber natürlich kann eine Klasse ein oder mehrere Interfaces 
implementieren...

> D.h. es müsste einen anderen Weg geben.

Wieso einen anderen? Das ist doch der Weg, mit dem es geht.

Bei Interfaces ohne eigenes aufwendiges Innenleben macht man es wirklich 
ganz direkt so, dass man es für jede Klasse implementiert, die es 
anbieten soll.

Für Interfaces mit umfangreichem "Eigenleben" macht man es hingegen so, 
dass man dieses Eigenleben in einer möglichst abstrakten 
Interfacehandlerklasse verfasst und dann passende Ableitungen davon für 
all die Klassen schreibt, die das Interface implementieren sollen. Der 
nervige Rest ist dann, dass man in jeder Instanz der eigentlichen 
Klassen auch eine Instanz des passenden Interfacehandlers erzeugen und 
das alles korrekt miteinander "verdrahten" muss. Das ist einfach mal 
deutlich mehr Schreibarbeit, als bei regulärer Vererbung anfällt. Der 
Denkaufwand hingegen ist so ziemlich der Gleiche.

Und das ist irgendwie auch gut so, denn das sorgt durchaus mit dafür, 
dass Interfaces nur dort eingesetzt werden, wo sie wirklich sinnvoll 
sind. Gott sei Dank sind Programmierer nämlich ein von Natur aus sehr 
schreibfaules Volk...

Eigentlich ist es so, dass nach der reinen OOP-Lehre sowas wie 
Interfaces überhaupt nicht existieren müsste. Blöd bloß, wenn 
existierende Vererbungshierarchien mit jeweils sehr viel Funktionalität 
miteinander verheiratet werden sollen. Dann hätte man theoretisch die 
Möglichkeit, den ganzen Kram aufzudröseln und eine einzige, vollständig 
OOP-konforme Hierarchie zu schaffen. Das ist aber dummerweise noch sehr 
viel mehr Sackstand als die Sache mit den Interfaces. Also nimmt man 
halt Interfaces...

von db8fs (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Man kann überhaupt nicht von Interfaces erben, weder von einem noch von
> mehreren. Aber natürlich kann eine Klasse ein oder mehrere Interfaces
> implementieren...

In C++ sollte man sich der Tatsache der Vererbung schon bewusst sein. 
Mit nicht-virtuellen/finalen Destruktoren (also dem Standarddestruktor) 
schafft man sonst u.U. schöne Memleaks bei dynamischer Allokierung.

Für Java/C# ist deine Terminologie allerdings korrekt.

> Eigentlich ist es so, dass nach der reinen OOP-Lehre sowas wie
> Interfaces überhaupt nicht existieren müsste.

Was ist denn die reine Lehre? Die OOP, die Smalltalk begründet hat? Da 
ist immer die Datenkapsel das Grundprinzip, also Trennung von 
Spezifikation und Implementierung (design by contract) innerhalb eines 
Übersetzungsmoduls.

Das hier gebrauchte 'Interface' ist doch letztlich nur eine weitere 
Abstraktion um die Interaktion zwischen Objekten zu vereinfachen - 
praktisch gewinnt doch der Begriff 'Interface' durch die Entwurfsmuster 
seine Bedeutung. Und in dem Rahmen kommt man das Konzept der abstrakten 
Klasse bzw. des Interfaces nicht drumrum.

> Blöd bloß, wenn
> existierende Vererbungshierarchien mit jeweils sehr viel Funktionalität
> miteinander verheiratet werden sollen. Dann hätte man theoretisch die
> Möglichkeit, den ganzen Kram aufzudröseln und eine einzige, vollständig
> OOP-konforme Hierarchie zu schaffen. Das ist aber dummerweise noch sehr
> viel mehr Sackstand als die Sache mit den Interfaces. Also nimmt man
> halt Interfaces...

Na ob das den reinen OOP-Gedanken widerspiegelt, sei mal dahingestellt. 
Wie gesagt, Interfaces haben sich in der COM-Programmierung als durchaus 
zweckmäßig erwiesen und durch wartbare Softwarekomponenten daraus 
entstehen lassen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.