erp-bt hat geschrieben: Nein, Du musst das Interface als abstrakt definieren, da Du es sonst nicht in der konkreten Klasse implementieren kannst. Du kriegst dann dort die Meldung Methode Interface-Methode ist in der Klasse Abstrakte-Klasse implementiert und das ist ja nicht das was wir wollen. Die Option ist ja nicht umsonst da. Wenn Du das Interface in der abstrakten Klasse abstrakt definierst, kannst Du in der konkreten Klasse ganz normal die Interface-Methode implementieren und alles was gemeinsam ist eben in der abstrakten Klasse.
Ich habe es mir einfach zur Gewohnheit gemacht zu einem Interface auch gleich eine abstrakte Klasse zu definieren, da es mir schlicht und einfach das Leben erleichtert. Muss man ja nicht machen, wenn man auch sonst zurecht kommt. Ich habe die Erfahrung gemacht das es äußerst hilfreich ist eine abstrakte Klasse zu haben, in der man gemeinsame Typen/Attribute/Methoden definieren und implementieren kann. Ob das für einen selbst sinnvoll oder nutzbar ist, steht auf einen ganz anderen Blatt. Deswegen habe ich ja geschrieben, einfach mal ausprobieren.
Viele Grüße, Tapio
Falls Du mich meinst, ja alle konkreten implementierenden Klassen erben von der abstrakten Klasse.ralf.wenzel hat geschrieben:Und alle das IF implementierende CL erben von der abstrakten Klasse?
Ralf
Hmm, jetzt gibt es also doch eine abstrakte Klasse die das Interface implementiert. Ob jetzt komplett abstrakt oder nur Teile davon lass ich einfach mal dahingestellt. Das hast Du ja vorher in Frage gestellt.gtoXX hat geschrieben:
Ich sage nochmal : Deine Beschreibung ist nicht genau. Ein Interface an sich ist bereits abstrakt. Natürlich kann ich 5 Methoden im Interface definieren. In der Abstrakten Klasse implementiere ich z.b. 3 die eine gemeinsame Funktionalität darstellen( oder z.b. eine als abstrakt deklarierte immer aufrufen.) . 2 deklariere ich als abstrakt in der Klasse um si edann später zu redefinieren.
Dem Nutzen widerspreche ich ja auch nicht, denn ich nutze es ebenfalls.
Ich persönlich sehe es halt als Vorteil an, wenn man nicht ständig das Interface anpassen muss, um dann evtl. gemeinsames Coding in einer abstrakten Klasse zu implementieren. Im BAdI-Fall habe ich ja sogar überhaupt nicht die Möglichkeit das Interface anzupassen und warum ich dann nicht das ganze Interface als abstrakt definieren soll, erschließt sich mir ehrlich gesagt nicht. Wie gesagt die Option ist ja nicht umsonst da.gtoXX hat geschrieben: Wozu noch eine Abstrakte Klasse ?
ralf.wenzel hat geschrieben:Das hab ich aber selten. Normalerweise ist es so, dass implementierende Klassen aus völlig verschiedenen Vererbungsbäumen. Sonst kann ich die Methoden gleich in der Oberklasse definieren.
Ralf
Wier meinen schon das Gleiche im Endeffekt.erp-bt hat geschrieben:
Ich persönlich sehe es halt als Vorteil an, wenn man nicht ständig das Interface anpassen muss, um dann evtl. gemeinsames Coding in einer abstrakten Klasse zu implementieren. Im BAdI-Fall habe ich ja sogar überhaupt nicht die Möglichkeit das Interface anzupassen und warum ich dann nicht das ganze Interface als abstrakt definieren soll, erschließt sich mir ehrlich gesagt nicht. Wie gesagt die Option ist ja nicht umsonst da.
Viele Grüße, Tapio
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
a-dead-trousers