ABAP OO
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Hallo Experten,
ich habe eine Frage an euch.
In Zukunft möchte ich versuchen meine Programme in OO zu schreiben, jedoch weiß ich nicht wie ich den Code am besten in die Klassen auslagern soll.
Wie macht ihr das immer? Könnt ihr mir da Tipps geben?
ich habe eine Frage an euch.
In Zukunft möchte ich versuchen meine Programme in OO zu schreiben, jedoch weiß ich nicht wie ich den Code am besten in die Klassen auslagern soll.
Wie macht ihr das immer? Könnt ihr mir da Tipps geben?
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 / 4286 / 214 /
1142
)
»
Am Beispiel eines Standardreports:
- Den Selektionsschirm im Report definieren (geht ja nur da).
- Eine eigene Klasse mit ähnlichem Namen im Repository anlegen.
- Im Ereignis START-OF-SELECTION die Klasse instanzieren.
- Die Klasse hat eigene SET_...-Methoden um die Parameter und Selektoptionen aus dem Selektionsschirm zu übergeben.
- Mit einer Methode (z.B. RUN) wird die Verarbeitung aufgerufen.
- Die Ausgabe der Daten kann dank REUSE-Baustein oder CL_SALV_TABLE direkt in der Klasse erfolgen.
Somit hat das Programm / der Report nur ganz wenig Coding und der Rest steckt alles in der Klasse.
Natürlich kann man dann auch die Funktionen weiter Modularisieren und z.B. für die Ausgabe eine eigene Klasse verwenden die noch zusätzliche, öfters verwendete Funktionen bietet.
Man könnte die Klasse zwar auch lokal im Programm definieren, dann spart man sich die SET_...-Methoden für die Parameterübergabe, man hat aber dann auch meines Erachtens kaum noch Vorteile aus dem OO, da man die Funktionalitäten der Klasse in anderen Programmen nicht mehr verwenden kann. Bestes Beispiel hierfür:
Gegeben sei ein Report X und nun soll ein RFC-fähiger Baustein erstellt werden, der genau die gleiche Verarbeitung bieten und die Daten z.B. für Crystal-Reports zur Verfügung stellen soll.
lg ADT
- Den Selektionsschirm im Report definieren (geht ja nur da).
- Eine eigene Klasse mit ähnlichem Namen im Repository anlegen.
- Im Ereignis START-OF-SELECTION die Klasse instanzieren.
- Die Klasse hat eigene SET_...-Methoden um die Parameter und Selektoptionen aus dem Selektionsschirm zu übergeben.
- Mit einer Methode (z.B. RUN) wird die Verarbeitung aufgerufen.
- Die Ausgabe der Daten kann dank REUSE-Baustein oder CL_SALV_TABLE direkt in der Klasse erfolgen.
Somit hat das Programm / der Report nur ganz wenig Coding und der Rest steckt alles in der Klasse.
Natürlich kann man dann auch die Funktionen weiter Modularisieren und z.B. für die Ausgabe eine eigene Klasse verwenden die noch zusätzliche, öfters verwendete Funktionen bietet.
Man könnte die Klasse zwar auch lokal im Programm definieren, dann spart man sich die SET_...-Methoden für die Parameterübergabe, man hat aber dann auch meines Erachtens kaum noch Vorteile aus dem OO, da man die Funktionalitäten der Klasse in anderen Programmen nicht mehr verwenden kann. Bestes Beispiel hierfür:
Gegeben sei ein Report X und nun soll ein RFC-fähiger Baustein erstellt werden, der genau die gleiche Verarbeitung bieten und die Daten z.B. für Crystal-Reports zur Verfügung stellen soll.
lg ADT
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 / 3776 / 176 /
262
)
»
Moin
ADT hat natürlich recht (wenngleich ich SOS fürs Instanziieren zu spät finde, es gibt ja noch andere Sekektionsbildereignisse, die vorher prozessiert werdeb(, einen wesentlichen Vorteil hat er aber nicht genannt: Man trennt das UI von der Business Logik, kann also den funktionierenden Prozess auch mit einer anderen UI verwenden.
Allerdings ist es nicht ganz so einfach, man sollte sich schon mit Thenen wie Layer-Architektur beschäftigen. Wenn man einfach nur den Code in Klassen schreibt, gewinnt man nicht viel. Man sollte schon abstrahieren und versuchen, Code, den man mehr als einmal braucht, in eine Serviceklasse zu packen. Auf diese Weise kann man z. B. alle DB-Zugriffe in speziellen Klassen durchführen (was dann bei einer HANA-Einführung heißt, dass man nur diese Klassen überarbeiten muss!), was insbesondere das Testen vereinfacht, weil man diese Zugriffe dann mocken kann.
Wenn du z. B. einen Auftrag im PP erzeugst, musst du eine bestimmte Folge von Funktionsbausteinen als Sequenz ausführen. Ab in eine dokumentierte Methode mit der Sequenz, dann muss das nie wieder wer neu erfinden - und das Know How landet da, wo es hingehört: Im System statt im Kopf eines Entwicklers.
Also: Entwurfsmuster lernen, Abstraktion anlesen, Softwarelayer-Architektur verstehen. Dann bist du auf einem guten Weg.
Ralf
ADT hat natürlich recht (wenngleich ich SOS fürs Instanziieren zu spät finde, es gibt ja noch andere Sekektionsbildereignisse, die vorher prozessiert werdeb(, einen wesentlichen Vorteil hat er aber nicht genannt: Man trennt das UI von der Business Logik, kann also den funktionierenden Prozess auch mit einer anderen UI verwenden.
Allerdings ist es nicht ganz so einfach, man sollte sich schon mit Thenen wie Layer-Architektur beschäftigen. Wenn man einfach nur den Code in Klassen schreibt, gewinnt man nicht viel. Man sollte schon abstrahieren und versuchen, Code, den man mehr als einmal braucht, in eine Serviceklasse zu packen. Auf diese Weise kann man z. B. alle DB-Zugriffe in speziellen Klassen durchführen (was dann bei einer HANA-Einführung heißt, dass man nur diese Klassen überarbeiten muss!), was insbesondere das Testen vereinfacht, weil man diese Zugriffe dann mocken kann.
Wenn du z. B. einen Auftrag im PP erzeugst, musst du eine bestimmte Folge von Funktionsbausteinen als Sequenz ausführen. Ab in eine dokumentierte Methode mit der Sequenz, dann muss das nie wieder wer neu erfinden - und das Know How landet da, wo es hingehört: Im System statt im Kopf eines Entwicklers.
Also: Entwurfsmuster lernen, Abstraktion anlesen, Softwarelayer-Architektur verstehen. Dann bist du auf einem guten Weg.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3947 / 105 /
886
)
»
Hallo Lukas,
ich möchte eine Amerkung machen was Auslagern in eine SE24 Klasse angeht.
Kann man machen. a-d-t und Ralf haben ja schon recht gut geschildert welchen Vorteil das hat. Aber ist halt auch Geschmackssache ab wann man anfängt auszulagern.
Denn man könnte genau so gut die gesamte Klasse zunächst im Programm definieren, ohne dass sich ein Unterschied ergibt. Wenn dir irgend wann mal auffällt, dass die Klasse tolle Funktionalitäten enthält, die du auch Anderen zur Verfügung stellen möchtest sind das dann nur ein paar Klicks um sich in der SE24 aus der programmlokalen Klasse eine DDIC-basierte Klasse erzeugen zu lassen, so dass du zunächst einmal nichts verlierst wenn du programmlokal arbeitest. Man kann eben auch programmlokal all das machen was Ralf anspricht ( Entwurfsmuster, MVC, etc ). Der Vorteil kommt halt erst bei der Wiederverwendbarkeit - und ich kenne genügend Reports, wo das nicht gegeben ist weil die so speziell sind, dass das keiner wirklich braucht.
Weiterhin gibt es diverse Dinge in einem Programm ( SelScreen bzw Dynpros , Ausgabe ) die so programmspezifisch sind, dass man die nun wirklich nicht in eine allgemeine Klasse auslagern muss sondern lokal halten sollte.
Nachteil ist allerdings, dass du hier nicht so schnell merkst, wenn du nicht sauber arbeitest ( z.B Zugriff auf SelOpts direkt in der Klasse anstatt diese vorher an die Klasse weiterzureichen ) weil es im Programm eben geht während es in der SE24 halt auch dem Compiler auffällt
Um beim Beispiel von a-d-t zu bleiben, wo im Nachhinein ein RFC-Fähiger Baustein gebildet werden soll. Hier müsstest du halt in der SE24 dir kurzerhand aus einer der programmlokalen Klassen die SE24-Version generieren lassen, im Programm die Definition und Implementierung der Klasse entsorgen und dann im Programm den lokalen Klassennamen durch den SE24-generierten Klassennamen ersetzen. Nicht wirklich viel Arbeit und die SE24 wird nicht mit abertausenden 1x Klassen vollgemüllt, was einem spätestens dann zu Gute kommt, wenn man mal nach einer Klasse suchen muss . In einem kleineren Heuhaufen findet sich die Nadel halt schneller
ich möchte eine Amerkung machen was Auslagern in eine SE24 Klasse angeht.
Kann man machen. a-d-t und Ralf haben ja schon recht gut geschildert welchen Vorteil das hat. Aber ist halt auch Geschmackssache ab wann man anfängt auszulagern.
Denn man könnte genau so gut die gesamte Klasse zunächst im Programm definieren, ohne dass sich ein Unterschied ergibt. Wenn dir irgend wann mal auffällt, dass die Klasse tolle Funktionalitäten enthält, die du auch Anderen zur Verfügung stellen möchtest sind das dann nur ein paar Klicks um sich in der SE24 aus der programmlokalen Klasse eine DDIC-basierte Klasse erzeugen zu lassen, so dass du zunächst einmal nichts verlierst wenn du programmlokal arbeitest. Man kann eben auch programmlokal all das machen was Ralf anspricht ( Entwurfsmuster, MVC, etc ). Der Vorteil kommt halt erst bei der Wiederverwendbarkeit - und ich kenne genügend Reports, wo das nicht gegeben ist weil die so speziell sind, dass das keiner wirklich braucht.
Weiterhin gibt es diverse Dinge in einem Programm ( SelScreen bzw Dynpros , Ausgabe ) die so programmspezifisch sind, dass man die nun wirklich nicht in eine allgemeine Klasse auslagern muss sondern lokal halten sollte.
Nachteil ist allerdings, dass du hier nicht so schnell merkst, wenn du nicht sauber arbeitest ( z.B Zugriff auf SelOpts direkt in der Klasse anstatt diese vorher an die Klasse weiterzureichen ) weil es im Programm eben geht während es in der SE24 halt auch dem Compiler auffällt
Um beim Beispiel von a-d-t zu bleiben, wo im Nachhinein ein RFC-Fähiger Baustein gebildet werden soll. Hier müsstest du halt in der SE24 dir kurzerhand aus einer der programmlokalen Klassen die SE24-Version generieren lassen, im Programm die Definition und Implementierung der Klasse entsorgen und dann im Programm den lokalen Klassennamen durch den SE24-generierten Klassennamen ersetzen. Nicht wirklich viel Arbeit und die SE24 wird nicht mit abertausenden 1x Klassen vollgemüllt, was einem spätestens dann zu Gute kommt, wenn man mal nach einer Klasse suchen muss . In einem kleineren Heuhaufen findet sich die Nadel halt schneller
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Da gibt es hier (bei meinem aktuellen Kunden) eine ganz einfache Definition: Keine lokalen Klassenblack_adept hat geschrieben:ich möchte eine Amerkung machen was Auslagern in eine SE24 Klasse angeht.
Kann man machen. a-d-t und Ralf haben ja schon recht gut geschildert welchen Vorteil das hat. Aber ist halt auch Geschmackssache ab wann man anfängt auszulagern.
Schon wegen der Trennung UI/Business-Logik.Eine mir sehr sympathische Regel.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4286 / 214 /
1142
)
»
Gute Regel.ralf.wenzel hat geschrieben:Da gibt es hier (bei meinem aktuellen Kunden) eine ganz einfache Definition: Keine lokalen Klassenblack_adept hat geschrieben:ich möchte eine Amerkung machen was Auslagern in eine SE24 Klasse angeht.
Kann man machen. a-d-t und Ralf haben ja schon recht gut geschildert welchen Vorteil das hat. Aber ist halt auch Geschmackssache ab wann man anfängt auszulagern.
Eine mir sehr sympathische Regel.
Außerdem finde ich die Klasse in der SE24 (oder in Eclipse) einfach übersichtlicher dargestellt, als wenn das Ganze im Programmcode herumlungert. Deffinition und Implementation müssen ja teilweise an unterschiedlichen Stellen definiert werden.
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 / 3776 / 176 /
262
)
»
Naja, mit dem Split-Screen-Editor und der Quelltextsicht in der SE24 bin ich jetzt nicht SO unglücklich..... Allerdings sperrt man damit die ganze Klasse, was nicht witzig ist, wenn man mit mehreren Entwicklern an einem Projekt arbeitet.a-dead-trousers hat geschrieben: Außerdem finde ich die Klasse in der SE24 (oder in Eclipse) einfach übersichtlicher dargestellt, als wenn das Ganze im Programmcode herumlungert. Deffinition und Implementation müssen ja teilweise an unterschiedlichen Stellen definiert werden.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3947 / 105 /
886
)
»
Warum?a-dead-trousers hat geschrieben:Definition und Implementation müssen ja teilweise an unterschiedlichen Stellen definiert werden.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Weil class..... implementation oft eine ganze Ecke weg liegt von class....definition, denke ich mal.black_adept hat geschrieben:Warum?a-dead-trousers hat geschrieben:Definition und Implementation müssen ja teilweise an unterschiedlichen Stellen definiert werden.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3947 / 105 /
886
)
»
Kann man machen - dir Frage bezog sich mehr auf das müssen.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Na, ist die Definition oder die Implementierung hinreichend lang, ist der Weg vom Methodencoding zu ihrer Schnittstelle recht weit. Viele Optionen gibt es da nicht.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3947 / 105 /
886
)
»
Stimmt - aber das unterscheidet doch nicht SE38 von SE24 oder eclipse ( wobei SE24 die Signatur im Kopf darstellt - das ist tatsächlich ein plus ).
Seite 1 von 1
Vergleichbare Themen
5
Antw.
Antw.
10034
Views
Views
Kundeneigene ABAP-Muster Vorlage im ABAP-Editor anlegen
von Stentor » 19.07.2005 11:10 • Verfasst in Basis
von Stentor » 19.07.2005 11:10 • Verfasst in Basis
3
Antw.
Antw.
3446
Views
Views
OLE und ABAP: Aufruf von Excel-VBA Prozeduren aus ABAP
von OnkelSAP » 26.05.2010 09:45 • Verfasst in ABAP Objects®
von OnkelSAP » 26.05.2010 09:45 • Verfasst in ABAP Objects®
2
Antw.
Antw.
3051
Views
Views
6
Antw.
Antw.
4628
Views
Views
ABAP Workbench und ABAP Dictionary - für Einsteiger
von schnonus » 03.04.2008 10:39 • Verfasst in ABAP® für Anfänger
von schnonus » 03.04.2008 10:39 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
15677
Views
Views
ABAP 7.02 - Neues Feature - Pragmas in ABAP
von foessleitnerj » 09.01.2013 17:02 • Verfasst in Tips + Tricks & FAQs
von foessleitnerj » 09.01.2013 17:02 • Verfasst in Tips + Tricks & FAQs
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
xlsx mit CL_SALV_TABLE aus interner Tabelle erstellen - kann man auch mehrere Tabreiter erzeugen?
vor einer Stunde von whaslbeck 9 / 95
vor einer Stunde von whaslbeck 9 / 95
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
xlsx mit CL_SALV_TABLE aus interner Tabelle erstellen - kann man auch mehrere Tabreiter erzeugen?
vor einer Stunde von whaslbeck 9 / 95
vor einer Stunde von whaslbeck 9 / 95