Abstrakte Klasse, welche meherere Interfaces "bündelt"

Hallo,

ich habe mehrere Interfaces für verschiedene Controls.

Nun möchte ich eine abstrakte basisklasse erstellen, welche alle diese Interfaces "implementiert", aber nur um sie "weiterzugeben".

Ich möchte quasi das meine controls nicht die interfaces implementieren, sondern diese basisklasse.

Allerdings kann ich ja die in den interfaces deklarierten methoden/properties in der klasse nicht als abstrakt kennzeichnen, somit werden die implementierenten controls nicht gezwungen die methoden zu überschreiben.
Ich könnte natürlich die abstrakte basisklasse als eine art adapter fungieren lassen, und um die methoden der interfaces einfach eine abstracte wrappermethode hüllen.

Aber geht es nicht besser?

Sinn und zweck ist, das ich eine Collection von der abstrakten Basisklasse haben möchte, egal welches Interface das Control selbst implementieren würde.

Wie kann ich soetwas am besten abbilden?

mfg
serial

Du kannst auch mehrere Inferfaces in einem neuen Interface zusammenfassen.

Der Sinn einer abstrakten Basisklasse ist ja auch u.a., dass man nicht alle Methoden selber erstellen muss. Überdenke daher ggf. dein Konzept.

EDIT: Sonst kannst du das auch über eine NotSupportedException lösen

Hallo See Sharp,

das mit dem zusammenfassen im Interface ist mir klar, allerdings soll die basisklasse noch einige methoden selbstständig ausführen und implementieren, aber eben nicht alle!

Ein großteil der interface-methoden soll "durchgereicht" werden...

mfg
serial

Hallo serial

Wieso nicht nur eine abstrakte Basisklasse?
Du musst ein bisschen konkreter werden, das man dich hier besser beraten kann.

Gruss Peter

Hallo Peter,

theoretisch hast du recht.
Muss das nochmal kurz überdenken.....kann wohl auf die seperaten interfaces wirklich verzeichtn, benötige sie glaub ich garnicht einzeln...!

ABER WENN, wie würde ich dann am besten vorgehen?

mfg
serial

Hallo serial

Die Antworten hast du doch schon.
Ich denke nicht das du sowas wirklich brauchst, aber wenn, wäre der Weg mit virtuell kennzeichen + eine NotImplementedException schmeissen wohl der gangbarste.

Gruss Peter

Hallo,

Allerdings kann ich ja die in den interfaces deklarierten methoden/properties in der klasse nicht als abstrakt kennzeichnen ...

    abstract class Test : IDisposable, IComparable<Test>
    {
        public abstract void Dispose();
        public abstract int CompareTo(Test other);
    }

Wieso sollte das nicht gehen?

Spooky

Hallo Spook,

weil mir da mein compiler sagt das ich die funktionen meiner interfaces nicht implementiere...

mfg
serial

Hallo serial,

es wäre ja kaum sinnvoll, wenn du in der Basisklasse alle Methoden abstrakt machen würdest, denn dann müsste ja jede Methode doch von der Unterklasse implementiert werden, und durch die Basisklasse wäre nichts gewonnen. Du könntest in diesem Szenario genauso gut die Interfaces direkt in den Unterklassen implementieren, ohne mehr Code schreiben zu müssen.

Also kann es ja nur darum gehen, dass du einzelne Methoden abstrakt machen willst. Dafür hast du die schon genannten beiden Möglichkeiten: entweder du packst solche Methoden in keins der Interfaces und kannst sie deshalb in der Oberklasse als abstract definieren oder packst die Methode in (mindestens) ein Interface und implementierst die Methode virtual und so, dass sie eine NotImplementedException wirft.

herbivore

Du solltest dir klar machen, wozu Basisklassen und Interfaces dienen. Interfaces sind Schnittstellen und Basisklassen sind Implementierungen.

Sinn und zweck ist, das ich eine Collection von der abstrakten Basisklasse haben möchte, egal welches Interface das Control selbst implementieren würde.

Das ist genau falsch rum. Das bedeutet schlussendlich: Es egal was es tut, es tut es gleich. Das ist ist schon offenbar Quatsch. Abtrakte Basisklassen sind nicht - wie z.B. in C++ gerne verwendet (da Mehrfachverberbung möglich)- ein Ersatz für Interfaces, sondern eben nur Klassen für Implementierungen ohne die Möglichkeit von Instanzen.

Hallo svenson,

im Sinne ganz oder gar nicht abstrakt hast du schon recht. Aber hier geht es ja darum, dass die Basisklasse bestimmte Teile vorgibt und andere (zwingend) den Unterklassen überlassen will (weshalb ja überhaupt abstract ins Spiel kommt). Die abstrakte Klasse, um die es geht, ist also nicht vollständig abstrakt (was sie ja in deinem C++-Vergleich sein müsste, um als Ersatz für Interfaces durchzugehen).

Natürlich hast du recht und ich denke, dass ist der Kern deiner Aussage, dass man sich überlegen sollte, für was Interfaces und für was (abstrakte) Basisklassen konzeptuell gut sind und nicht einfach nur danach gucken sollte, was man wie schreiben muss, damit man technisch hinbekommt, was man will. Das entspricht ungefähr dem, was ich in Abstrakte Klasse vs Interface gesagt habe).

herbivore

Hallo,

also Ihr habt schon recht, auf Interfaces kann ich verzichten.

Mir haben eben einige Beitäge zu diesem Thema zu denken gegeben (abstr. Klasse für Elemente welche logisch fast gleich sind, und Interfaces für komplett unterschiedliche Objekte).

Mein Zweck ist eben folgender:

Ich erstlle verschiedene UserControls die in 3 Gruppen geteilt sind.
Jede Gruppe hat ihre eigenen Eigenschaften und Methoden.

Die Gruppen unterscheiden sich untereinander stark.

Nun möchte ich aber eine Klasse, welche Controls, egal von welcher Gruppe, verwalten kann, und auch dessen Member benutzt.

Darum dachte ich eben an eine abstrake Basisklasse....mein Zweifel kam eben auf Grund der komplett unterschiedlichen Methoden und Eigenschaften der verschiedenen Gruppen.
Aber die abstrakte Klasse könnte ja Zugriffe auf nicht implementierte Methoden zentral behandeln.
Weiterhin gibt es teilweise gleiche funktionalitäten die gleich in der basisklasse ausgeführt werden, und nur teile durch die Controls selbst implementiert werden (template methode).

Also ich denke ich bin hier mit der abstrakten Klasse wirklichrichtig dran und verzichte auf Interfaces.

Danke euch allen