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!
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
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!
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.
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.
>>@ Autor: D. I. (grotesque)
Stimmt, geht auch in C# das eine Klasse mehrer Inetrfaces implementiert.
War mir nicht bewusst. Musste ich eben nachschauen.
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.
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.
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
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...
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.
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten