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? https://en.wikipedia.org/wiki/Interface_segregation_principle
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.
1 | class UltraFatMonsterClassWhichInheritsFromOneBaseClassAndImplementsManyInterfacesAtOnce : UltraFatMonsterBaseClass, IPersister, ISerializer, IDeserializer, ICommunicator, IEnumerable, IStuffMaker {}
|
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.