Klassennamen / Intefacenamen
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von black_adept (Top Expert / 4117 / 129 /
952
)
»
Da ABAP nur für Interfaces aber nicht für Klassen Mehrfachvererbung kennt, meinst du wahrscheinlich was anderes. Daher etwas anders formuliert: Welche der Klassen in deinem Konstrukt implementiert denn mehrere Interfaces? Und werden dann für diese Klasse jeweils unterschiedliche Mockklassen pro Interface einzeln aktiviert und deaktiviert?a-dead-trousers hat geschrieben:Wegen der Mehrfachvererbung (oder so ähnlich) die ich bei reiner Klassenvererbung nicht habe.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Nein, ich meinte schon die Mehrfachvererbung, aber da gibt es für Interfaces, soweit ich mich noch an meine Schulzeit erinnern kann, eine andere Bezeichnung. Weil man ja so nicht das Coding mehrfach vererben kann (wie in z.B. in C++) sondern nur die Schnittstellen.black_adept hat geschrieben:Da ABAP nur für Interfaces aber nicht für Klassen Mehrfachvererbung kennt, meinst du wahrscheinlich was anderes. Daher etwas anders formuliert: Welche der Klassen in deinem Konstrukt implementiert denn mehrere Interfaces? Und werden dann für diese Klasse jeweils unterschiedliche Mockklassen pro Interface einzeln aktiviert und deaktiviert?a-dead-trousers hat geschrieben:Wegen der Mehrfachvererbung (oder so ähnlich) die ich bei reiner Klassenvererbung nicht habe.
Um beim DAO Paradigma zu bleiben, denn da hatte ich vor kurzem einen konkreten Anwendungsfall:
In RDBMS-Systemen (was SAP/Oracle zumindest versuchen zu sein) legt man ja die Daten nicht in nur einer Tabelle ab. Da gibt es z.B. Rechnungskopf (VBUK) und Rechnungsposition (VBUP). DAOs sollten so "einfach" wie möglich gehalten sein, also nur simple SELECTs auf eine Tabelle machen. Wenn ich nun einen Mock schreiben wollte, müsste ich pro Tabelle die Daten in jeweils eigenen Objekten vorhalten. Diese Daten haben somit keine "direkte" Relevanz zueinander. Das ist insofern blöd, wenn man damit (Standard-)Geschäftsfälle abbilden möchte. Also verwende ich nun anstatt mehrerer "klassischer" Mockklassen eine einzige (pro Geschäftsfall) welche die Interfaces von allen betroffenen Tabellen enthält. Somit sind, um beim Beispiel zu bleiben, die "gemockten" Kopf- und Positionsdaten der Rechnung in einer einzigen Klasse hinterlegt, die sowohl für den DAO der VBUK als auch der VBUP die Interfaces implementiert hat. Wenn man das Ganze dann noch im Repository und nicht in den Testincludes (Testklassen) ablegt, können mehrere Tests dieselben Datenbestände nutzen.
Also implementieren die Mockklassen meiner DAOs mehrere Interfaces um ganze Geschäftsfälle besser abzubilden. Die Klassen, die die DAOs verwenden sollen, haben eigene public SET-Methoden um die DAOs von außerhalb verändern zu können. Ist bei einem Zugriff auf einen DAO dieser noch nicht per SET übergeben worden, wird das Objekt mit der Default-Implementierung (gleicher Name wie Interface) instanziert, die den Zugriff auf die Datenbank beinhaltet. Somit hat der Verwender des DAO standardmäßig immer den Zugriff auf die Datenbank und nur wenn man das explizit ausprogrammiert (z.B. in einer Testklasse) wird der Mock verwendet.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4117 / 129 /
952
)
»
Ok - verstanden und Begründung "DAO möglichst einfach" akzeptiert.
Und verfrachtest du dann für einen Beleg die diversen zugehörigen Interfaces in ein Sammelinterface welches dann in die Klasse übernommen wird oder schreibst du dann je nach Anwendungsfall genau die benötigten Tabellen eine neue Defaultimplementierung
Und verfrachtest du dann für einen Beleg die diversen zugehörigen Interfaces in ein Sammelinterface welches dann in die Klasse übernommen wird oder schreibst du dann je nach Anwendungsfall genau die benötigten Tabellen eine neue Defaultimplementierung
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Das mit den "Sammelinterfaces" mach ich bei den DAOs nicht 
Die verwende ich meist bei den "höheren" APIs. Grundsätzlich hab ich mehrere Interfaces für Standard-Funktionen:
ZIF_LOCKABLE für die Anbindung von Sperren.
ZIF_AUTHORIZING für die Anbindung von Berechtigungen.
ZIF_CACHING für eine Änderungsverfolgung.
ZIF_CONNECTIVE für RFC-Kommunikation.
Aus diesen (und noch weiteren) bastel ich mir dann je Anwendungsfall ein "Sammelinterface" zu dem es dann auch eine Defaultimplementierung gibt.
Wenn man so will entsteht so ein Interface ZIF_RECHNUNG, dass eine Rechnung samt Positionen abbildet, zur Laufzeit Änderungen an den Daten mit Snapshots verwaltet, die Berechtigungen prüft und nach Wunsch die Daten per RFC auf anderen Systemen/Mandanten verbuchen kann. Wobei die Anbindung an die Datenbank eben über die DAOs läuft und somit diese entkoppelt werden kann damit man keine Testdaten vorhalten muss.
Die verwende ich meist bei den "höheren" APIs. Grundsätzlich hab ich mehrere Interfaces für Standard-Funktionen:
ZIF_LOCKABLE für die Anbindung von Sperren.
ZIF_AUTHORIZING für die Anbindung von Berechtigungen.
ZIF_CACHING für eine Änderungsverfolgung.
ZIF_CONNECTIVE für RFC-Kommunikation.
Aus diesen (und noch weiteren) bastel ich mir dann je Anwendungsfall ein "Sammelinterface" zu dem es dann auch eine Defaultimplementierung gibt.
Wenn man so will entsteht so ein Interface ZIF_RECHNUNG, dass eine Rechnung samt Positionen abbildet, zur Laufzeit Änderungen an den Daten mit Snapshots verwaltet, die Berechtigungen prüft und nach Wunsch die Daten per RFC auf anderen Systemen/Mandanten verbuchen kann. Wobei die Anbindung an die Datenbank eben über die DAOs läuft und somit diese entkoppelt werden kann damit man keine Testdaten vorhalten muss.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das ist jetzt vllt eine blöde Frage, aber warum DAO-Klassen schreiben, wenn es BOPF gibt?
Ralf
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
a-dead-trousers
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Weil ich das bislang noch nicht kannte
Schaut auch interessant aus. Muss ich mir mal näher zu Gemüte führen.
Ich hab meine "Art" der DAOs entwickelt, weil mir die persistenten Klassen der SAP einfach zu unflexibel waren. z.B. Daten- und Texttabelle (mit Sprachkennzeichen) lassen sich nicht einfach so, ohne manueller Eingriffe, verbinden. Vielleicht bietet BOPF da ja einen besseren Ansatz.
Schaut auch interessant aus. Muss ich mir mal näher zu Gemüte führen.
Ich hab meine "Art" der DAOs entwickelt, weil mir die persistenten Klassen der SAP einfach zu unflexibel waren. z.B. Daten- und Texttabelle (mit Sprachkennzeichen) lassen sich nicht einfach so, ohne manueller Eingriffe, verbinden. Vielleicht bietet BOPF da ja einen besseren Ansatz.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Weil es zum Thema passt:
Wie ich jetzt gerade nochmal in die persistenten Klassen reingeschaut hab, ist mir aufgefallen, dass die SAP hier ja sehr stark mit den Präfixen arbeitet.
Wenn man eine p. Klasse anlegt werden gleichzeitig eine CA und CB Klasse anlegt. Auch muss der Klassenname selbst mit CL beginnen.
Wie ich jetzt gerade nochmal in die persistenten Klassen reingeschaut hab, ist mir aufgefallen, dass die SAP hier ja sehr stark mit den Präfixen arbeitet.
Wenn man eine p. Klasse anlegt werden gleichzeitig eine CA und CB Klasse anlegt. Auch muss der Klassenname selbst mit CL beginnen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Halte uns mal über deine Erkenntnisse auf dem Laufenden, über BOPF wissen sehr viele noch viel zu wenig.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Persistente Klassen habe ich mal im Zuge eines Projektes ausprobiert und direkt verworfen, weil es sich nicht verwenden ließ (ich hab mich hier darüber sehr ausgelassen, müsste man noch finden können).a-dead-trousers hat geschrieben:Weil es zum Thema passt:
Wie ich jetzt gerade nochmal in die persistenten Klassen reingeschaut hab, ist mir aufgefallen, dass die SAP hier ja sehr stark mit den Präfixen arbeitet.
Wenn man eine p. Klasse anlegt werden gleichzeitig eine CA und CB Klasse anlegt. Auch muss der Klassenname selbst mit CL beginnen.
Aber ja, das ist da insbesondere deshalb so, weil das meiste ja generiert wird.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wozu noch eine Abstrakte Klasse ? Ein Interface ist nichts anderes, als eine Sonderform einer Abstrakten Klasse die keine Implementierungen besitzt. Der Sinn einer abstrakten Klasse, ist ja, dass sie teilweise Logik enthalten kann. Aber nicht muss. Ich kann somit ein Grundverhalten implementieren, und wiederum spezifische Teile dann wieder selbst als abstrakt definieren.erp-bt hat geschrieben:Also ich lege ja meistens eine abstrakte Klasse pro Interface an. Die abstrakte Klasse kann ja dann das Interface auch wieder abstrakt definieren, sodass die konkrete Implementierung des Interface auch wieder in der konkreten Klasse erfolgt. Das funktioniert natürlich auch für mehrere Interfaces. So habe ich eigentlich immer eine hohe Fexibilität und zusätzlich den Vorteil das ich gemeinsam genutztes Coding wunderbar in die abstrakte Klasse packen kann. Solltet ihr mal ausprobieren.
Die Präfixe erachte ich persönlich auch für überflüssig, zumal in der OO-Theorie es ja völlig egal sein sollte ob man jetzt ein Interface oder eine Klasse aufruft. Das von adt beschriebene Modell habe ich aber auch schon öfters gesehen.
Viele Grüße, Tapio
Soll alles abstrakt sein, nehme ich ein Interface. Dann bin ich unabhängig von einer Vererbungshierarchie. Außer sie wäre absolut gewollt. Ist sie aber in allem abstrakt, hat sie m.E. nicht viel Sinn.
"Code lügt nicht ^^"
Weil nicht jeder moderne Releases von SAP einsetzt ^^. Der Vorteil der Verwendung SAP unabhängigen Entwicklungsdesigns ist eben die Unabhängigkeit von SAP.ralf.wenzel hat geschrieben:Das ist jetzt vllt eine blöde Frage, aber warum DAO-Klassen schreiben, wenn es BOPF gibt?
Ralf
So sehr man es sich auch wünscht, es gibt immer einen enormen Zeitverzug bis aktuelle Technologien überall zur Verfügung stehen. Manche überschreiten sogar den Lifecycle von von SAP erstellten Modulen. Irgendwo hörte ich auch schon vom Tod vom FPM z.b. Dein Beispiel zu Persistzenobjekten zeigt es ja auch. Teilweise kompliziert und schwerfällig.
Warum deswegen aber auf erprobte Designpatterns etc. verzichten ? Aktuell arbeite ich z.b. sehr viel mit DI. Dafür wurde ein eigener Injektor geschaffen. Dieser instanziert z.b. Serviceklassen. Im Constructor enthalten diese ihre abhängigen Objekte ( DAOs, CAO und andere Services ), welche automatisch mit instanziiert werden. Somit sind sie leicht mockbar.
"Code lügt nicht ^^"
Macht total Sinn. Du kannst in einem Interface kein Coding hinterlegen, müsstest es also in jeder Klasse die das Interface implementiert eine Methode neu implementieren. Mit einer abstrakten Klasse dazwischen, kannst Du gemeinsames Coding wunderbar in der abstrakten Klasse implementieren. Ich nutze das ständig, z.B. bei BAdI-Implementierungen. Du hast ein von SAP definiertes BAdI-Interface. Du hast unterschiedliche BAdI-Implementierungen, je nach Anwendungsfall. Du kannst jetzt alle gemeinsam genutzten Attribute, Typen und Methoden die Du für Deine individuellen BAdI-Implementierungen benötigst, in der abstrakten Klasse definieren und implementieren (in dem Fall kannst Du sogar noch nicht mal das Interface ändern da SAP Standard). Die konkrete BAdI-Implementierung erbt dann von der abstrakten Klasse, die das BAdI-Interface abstrakt definiert. Probier's einfach mal aus.gtoXX hat geschrieben:Wozu noch eine Abstrakte Klasse ? Ein Interface ist nichts anderes, als eine Sonderform einer Abstrakten Klasse die keine Implementierungen besitzt. Der Sinn einer abstrakten Klasse, ist ja, dass sie teilweise Logik enthalten kann. Aber nicht muss. Ich kann somit ein Grundverhalten implementieren, und wiederum spezifische Teile dann wieder selbst als abstrakt definieren.erp-bt hat geschrieben:Also ich lege ja meistens eine abstrakte Klasse pro Interface an. Die abstrakte Klasse kann ja dann das Interface auch wieder abstrakt definieren, sodass die konkrete Implementierung des Interface auch wieder in der konkreten Klasse erfolgt. Das funktioniert natürlich auch für mehrere Interfaces. So habe ich eigentlich immer eine hohe Fexibilität und zusätzlich den Vorteil das ich gemeinsam genutztes Coding wunderbar in die abstrakte Klasse packen kann. Solltet ihr mal ausprobieren.
Die Präfixe erachte ich persönlich auch für überflüssig, zumal in der OO-Theorie es ja völlig egal sein sollte ob man jetzt ein Interface oder eine Klasse aufruft. Das von adt beschriebene Modell habe ich aber auch schon öfters gesehen.
Viele Grüße, Tapio
Soll alles abstrakt sein, nehme ich ein Interface. Dann bin ich unabhängig von einer Vererbungshierarchie. Außer sie wäre absolut gewollt. Ist sie aber in allem abstrakt, hat sie m.E. nicht viel Sinn.
Viele Grüße, Tapio
...entwickelnder Berater...beratender Entwickler
Es ging explizit um den Teil. Da beschreibst Du ja das Interface wieder als abstrakt zu definieren. Und das hat eben keinen Sinn, wenn es sich auf das komplette Interface bezieht. Mit dem Rest sind wir ja konform, das eine Grundlogik implementiert wird und ein Teil dann abstrakt ist. Wobei ich für eine abstrakte Methode nicht zwingend eine abstrakte Klasse brauche.erp-bt hat geschrieben:gtoXX hat geschrieben:erp-bt hat geschrieben:Also ich lege ja meistens eine abstrakte Klasse pro Interface an. Die abstrakte Klasse kann ja dann das Interface auch wieder abstrakt definieren,
Viele Grüße, Tapio
"Code lügt nicht ^^"
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.gtoXX hat geschrieben: Es ging explizit um den Teil. Da beschreibst Du ja das Interface wieder als abstrakt zu definieren. Und das hat eben keinen Sinn, wenn es sich auf das komplette Interface bezieht. Mit dem Rest sind wir ja konform, das eine Grundlogik implementiert wird und ein Teil dann abstrakt ist. Wobei ich für eine abstrakte Methode nicht zwingend eine abstrakte Klasse brauche.
Im übrigen ist das auch keine Erfindung von mir, sondern wird häufig in den unterschiedlichsten Entwurfsmustern verwendet, wie z.B. dem Decorator-Pattern.
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
Zuletzt geändert von erp-bt am 02.04.2018 20:10, insgesamt 1-mal geändert.
...entwickelnder Berater...beratender Entwickler
Vergleichbare Themen
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.