Globale Klassen oder Lokale Klassen
Hallo,
ich wollte hier nachfragen, ob ihr lokale Klasse oder globale Klassen verwendet für ein Report?
Ich finde das Arbeiten mit globalen Klassen angenehmer! Ich frage mich jedoch, ob ich eine globale Klasse anlegen soll, wenn ich ein Report erstelle und diese Klasse nur im Report verwende und sonst nicht.
ich wollte hier nachfragen, ob ihr lokale Klasse oder globale Klassen verwendet für ein Report?
Ich finde das Arbeiten mit globalen Klassen angenehmer! Ich frage mich jedoch, ob ich eine globale Klasse anlegen soll, wenn ich ein Report erstelle und diese Klasse nur im Report verwende und sonst nicht.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Ich zitiere mal aus dem Clean-ABAP-Manifest:
Trotzdem haben meiner Ansicht nach lokale Klassen durchaus ihre Daseinsberechtigung, insbesondere wenn es um kleinere Funktionalitäten gibt, die nur im Kontext des einen Reports Sinn machen - z.B. bei nicht wirklich ABAP-OO-fähige Dynprosteuerung, SALV-Klassen, GUI-Status, etc. Auch wenn ein Report globale Klassen verwendet kann es sinnvoll sein, den Ereignis-Ablauf im Report mit einer lokalen Klasse mit PBO, PAI, INIT, etc. - Methoden zu strukturieren.Global als Standard, lokal nur im Bedarfsfall
Arbeiten Sie standardmäßig mit globalen Klassen. Verwenden Sie lokale Klassen nur, wo geeignet.
Globale Klassen sind die Klassen, die im Data Dictionary sichtbar sind. Lokale Klassen existieren innerhalb des Includes eines anderen Entwicklungsobjekts und sind nur für dieses andere Objekt sichtbar.
Lokale Klassen eignen sich
für sehr spezifische private Datenstrukturen, z.B. einen Iterator für die Daten der globalen Klasse, der ausschließlich hier benötigt wird,
um einen komplexen privaten Algorithmus zu extrahieren, z.B. zur Trennung dieses speziellen Multi-Methoden-Sortier-Aggregat-Algorithmus vom Rest des Codes Ihrer Klasse,
damit bestimmte Aspekte der globalen Klasse gedoublet werden können. So kann man beispielsweise alle Datenbankzugriffe in eine separate lokale Klasse extrahieren, die in Unit Tests dann durch ein Test-Double ersetzt werden kann.
Lokale Klassen verhindern die Wiederverwendung, weil sie nicht an anderer Stelle verwendet werden können. Obwohl sie einfach zu extrahieren sind, ist es schwer, sie überhaupt zu finden. Dies führt zu unerwünschter Codeduplizierung. Orientierung, Navigation und Debugging in sehr langen Includes lokaler Klassen sind mühsam und lästig. Da ABAP auf Include-Ebene sperrt, können an den verschiedenen Teilen des lokalen Includes nicht mehrere Personen gleichzeitig arbeiten (was möglich wäre, wenn es sich um separate globale Klassen handeln würde).
Überdenken Sie Ihre Verwendung von lokalen Klassen, wenn
- Ihr lokales Include Dutzende von Klassen und Tausende von Codezeilen umfasst,
- Sie globale Klassen als „Pakete“ betrachten, die andere Klassen enthalten,
- Ihre globalen Klassen zu leeren Hülsen degenerieren,
- Sie doppelten Code über separate lokale Includes hinweg wiederholt finden,
- Ihre Entwickler beginnen, sich gegenseitig auszusperren, und zunehmend unfähig werden, parallel zu arbeiten,
- Ihre Backlog-Schätzung durch die Decke geht, weil Ihre Teams die lokalen Includes der jeweils anderen Teams nicht mehr verstehen
Dem schließe ich mich an.
Ich bin inzwischen dazu übergegangen, mehr mit lokalen Klassen zu arbeiten.
a)
z.B. wenn ich eine Factory-Klasse habe, dann liefert diese eine lokal Klasse über get_instance() zurück. Das verhindert, dass die Funktionen der lokalen Klasse irgendwo zweckentfremdet werde.
b)
Bei Reports nehme ich inzwischen auch lokale Klassen, wenn diese Funktionen nur für den Report gedacht sind. Damit kann ich z.B. innerhalb des Reports mit den Klassen machen was ich will, ohne Gefahr zu laufen, dass diese extern zweckentfremdet werden. Hinzu kommt - auch bei den Faktory-Klassen - dass ich auch die DAO und Unit-Test darin packe. Die SAP sieht ja offiziell für die Unit-Test Includes mit dem Suffix *T99 vor.
c)
In der Funktionsgruppe nehme ich auch lokale Klassen für Unit-Test. Darin kann man dann auch FORM-Routinen rufen und somit diese testen. Das wäre mit globalen Klassen nicht möglich.
Und ja, man könnte in den Funktionsgruppen auf FORM-Routinen verzichten. Aber wenn man sich z.B. im BDT bewegt, sollte man so einheitlich wie möglich programmieren und nicht jedes mal den Aufbau des Quellcodes neu erfinden. Das macht die Verständlichkeit leichter.
Ich nutze für meine Demoprogramme im Tricktresor fast nur Programme mit lokalen Klassen. Einfach aus dem Grund, weil man alles mit Copy aus dem Tricktresor und Paste in die SE38 kopieren und direkt testen kann. Wenn man sich erstmal 5 Klassen anlegen muss, nervt es schnell. Zudem müllen die lokalen Klassen das Repository nicht voll. Wenn aus dem lokalen Testprogramm eine globale Version wird, lassen sich die lokalen Klassen leicht in globale Klassen übernehmen.
Danke!
Das Buch Clean ABAP hat mich etwas verunsichert gehabt, daher die Frage!
Verwendet ihr für die Klassen dann eigene Includes? Jeweils ein Include für eine Klasse? Trennt ihr die Definition und Implementierung in den Includes?
Das Buch Clean ABAP hat mich etwas verunsichert gehabt, daher die Frage!
Verwendet ihr für die Klassen dann eigene Includes? Jeweils ein Include für eine Klasse? Trennt ihr die Definition und Implementierung in den Includes?
Ich nicht. Die Includes für die anderen Elemente kommen auch nur daher, dass die SE80 das bei der Anlage automatisch vorschlägt und es schneller geht, zweimal ENTER zu drücken, als die Option mit der Maus abzuwählen. Finde ich auch doof, dass man das Verhalten nirgends deaktivieren kann.
Bei Funktionsgruppen kommen Klassendefinition und Klassenimplementierung in die dafür vorgesehenen Includes, "weil sich das so gehört".
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Ich verwende für "normale" Reports gar keine Includes, es sei denn sie werden zu groß. Dann versuche ich sinnvolle "Einheiten" in Includes auszulagern, wobei sich hier dann Klassen oder alles was mit der Selektionsbildverarbeitung zu tun hat anbieten. Und ich trenne dann üblicherweise in einen Include mit allen Klassendefinitionen und einen (oder mehrere bei sehr! groß gewordenen Programmen ) mit allen Implementierungen.
Aber ich schätze, dass >90% meiner aktuell geschriebenen Programme ohne Includes daher kommen.
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Da ich heutzutage Reports ohne FORM-Routinen schreibe, benötige ich halt Klassen um das Coding zu strukturieren. Da die Klasse erst mal nur für dieses eine Programm benötigt wird, wird sie auch nur lokal angelegt. Das entspricht in etwa den alten FORM-Routinen, die ja auch üblicherweise nur für ein Programm gedacht waren.
Das gleiche gilt für Strukturen und Typen, die nur für dieses eine Programm benötigt werden. Damit mülle ich das DDIC auch nicht zu. Allerdings muss ich zu meiner Schande gestehen, dass ich öfters mal für die ALV-Ausgabe eine DDIC-Struktur anlege, da man in der SE11 ein paar Sachen hinterlegen kann, die so in der lokalen Typedefinition nicht gehen.
Shame on me. But then I am quite shame resistent.
Beitrag
von sap_enthusiast (ForumUser / 95 / 25 /
23
)
»
Ich würde mich mit einer weiteren Fragestellung an euch wenden.
Wie steht ihr zu statischen bzw. Instanzmethoden? Ist es generell falsch, statische Kapselung zu bevorzugen?
Wie steht ihr zu statischen bzw. Instanzmethoden? Ist es generell falsch, statische Kapselung zu bevorzugen?
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Lokale Klassen: Meist Jacke wie Hosesap_enthusiast hat geschrieben: ↑30.11.2022 13:28Ich würde mich mit einer weiteren Fragestellung an euch wenden.
Wie steht ihr zu statischen bzw. Instanzmethoden? Ist es generell falsch, statische Kapselung zu bevorzugen?
Globale Klassen: Alles hat seine Berechtigung im richtigen Kontext. Kann man so kaum allgemein beantworten.
sap_enthusiast hat geschrieben: ↑30.11.2022 13:28Ich würde mich mit einer weiteren Fragestellung an euch wenden.
Wie steht ihr zu statischen bzw. Instanzmethoden? Ist es generell falsch, statische Kapselung zu bevorzugen?
spricht man, aber hier dann nicht von einer Art Funktionsbausteinen?
Laut dem Buch Clean ABAP, sollte man daher Instanzmethoden verwenden..
Wie Black_adept geschrieben hat: generell kann man das nicht beantworten.
statische Methoden können nicht vererbt werden.
für einige Entwurfsmuster benötigst du statische Methoden (z.B. Factory Pattern)
statische Methoden können nicht vererbt werden.
für einige Entwurfsmuster benötigst du statische Methoden (z.B. Factory Pattern)
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Also, hier werden in meinen Augen einige Sachen durcheinandergeworfen.
Grundsätzlich sind globale Klassen "besser", weil man sie wiederverwenden kann. Und Wiederverwendung ist einer der wichtigsten Punkte bei der OO. Ich arbeite streng nach dem Prinzip "ich löse ein Problem im System nur einmal" und das geht mit lokalen Klassen nicht.
Was ich sehr wohl mache, ist z. B. das Verwalten einer internen Tabelle innerhalb einer globalen Klasse als lokale Klasse umzusetzen. Also z. B. einen Iterator zu verwenden oder bestimmte Zustände abzufragen.
Bei meinem jetzigen Kunden werden in globalen Klassen viele lokale Klassen geschrieben nach dem Motto "wenn das noch einer braucht kann man die immer noch globalisieren" -- wobei ich das die falsche Herangehensweise finde, weil ich ja gar nicht weiß, was alles in lokalen Klassen codiert ist. Darum wird dort so manches Rad auch mehrfach erfunden.
Bei der Frage "statische Methoden vs. Instanzmethoden" verstehe ich die Frage gar nicht, weil das völlig unterschiedliche Dinge sind. Wenn ich eine Klasse habe, von der ich eine Instanz bauen will (und das ist fast immer der Fall, was mein Coding angeht), dann kann ich mit statischen Methoden nichts anfangen. Wenn ich nicht mit Objekten arbeiten will, brauche ich eigentlich keine Klasse, da reicht dann auch eine Funktionsgruppe. Wobei statische Klassen EINEN Vorteil (gegenüber Funktionsgruppen) haben: Die neue Schreibweise zerschneidet nicht das Coding. Darum habe ich mal bei einem Kunden eine Klasse geschrieben für lauter Konvertierungen (MATNR etc.), die bestand nur aus statischen Methoden. Einziger Zweck dieser Klassen war, die neue Schreibweise in Kettenausdrücken verwenden zu können.
Da gab es mal einen Disput mit Daniel, der genau DAS nicht verstanden hat und diese Methoden als schlechtes Beispiel dafür verwenden wollte, warum Klassen doof sind und nix bringen.
Ansonsten: Instanzen bilden, im Zweifel mit Singleton-Pattern. Sonst schneidet man sich einen Haufen Funktionalitäten ab, nämlich alle Patterns und praktisch alle Möglichkeiten des OO.
Wer sich solche Fragen stellt, hat vielleicht nicht genug über die Unterschiede von konventioneller und objektorientierter Programmierung nachgedacht. Im OO geht es um "Entitäten mit Eigenschaften und Verhaltensweisen" (Objekte) und die Kommunikation untereinander (durch Methodenaufrufe). Das "Programm" stöpselt diese Objekte nur noch zusammen. Das ist etwas vollkommen anderes, als ein konventioneller Report macht.
Ralf
Grundsätzlich sind globale Klassen "besser", weil man sie wiederverwenden kann. Und Wiederverwendung ist einer der wichtigsten Punkte bei der OO. Ich arbeite streng nach dem Prinzip "ich löse ein Problem im System nur einmal" und das geht mit lokalen Klassen nicht.
Was ich sehr wohl mache, ist z. B. das Verwalten einer internen Tabelle innerhalb einer globalen Klasse als lokale Klasse umzusetzen. Also z. B. einen Iterator zu verwenden oder bestimmte Zustände abzufragen.
Bei meinem jetzigen Kunden werden in globalen Klassen viele lokale Klassen geschrieben nach dem Motto "wenn das noch einer braucht kann man die immer noch globalisieren" -- wobei ich das die falsche Herangehensweise finde, weil ich ja gar nicht weiß, was alles in lokalen Klassen codiert ist. Darum wird dort so manches Rad auch mehrfach erfunden.
Bei der Frage "statische Methoden vs. Instanzmethoden" verstehe ich die Frage gar nicht, weil das völlig unterschiedliche Dinge sind. Wenn ich eine Klasse habe, von der ich eine Instanz bauen will (und das ist fast immer der Fall, was mein Coding angeht), dann kann ich mit statischen Methoden nichts anfangen. Wenn ich nicht mit Objekten arbeiten will, brauche ich eigentlich keine Klasse, da reicht dann auch eine Funktionsgruppe. Wobei statische Klassen EINEN Vorteil (gegenüber Funktionsgruppen) haben: Die neue Schreibweise zerschneidet nicht das Coding. Darum habe ich mal bei einem Kunden eine Klasse geschrieben für lauter Konvertierungen (MATNR etc.), die bestand nur aus statischen Methoden. Einziger Zweck dieser Klassen war, die neue Schreibweise in Kettenausdrücken verwenden zu können.
Da gab es mal einen Disput mit Daniel, der genau DAS nicht verstanden hat und diese Methoden als schlechtes Beispiel dafür verwenden wollte, warum Klassen doof sind und nix bringen.
Ansonsten: Instanzen bilden, im Zweifel mit Singleton-Pattern. Sonst schneidet man sich einen Haufen Funktionalitäten ab, nämlich alle Patterns und praktisch alle Möglichkeiten des OO.
Wer sich solche Fragen stellt, hat vielleicht nicht genug über die Unterschiede von konventioneller und objektorientierter Programmierung nachgedacht. Im OO geht es um "Entitäten mit Eigenschaften und Verhaltensweisen" (Objekte) und die Kommunikation untereinander (durch Methodenaufrufe). Das "Programm" stöpselt diese Objekte nur noch zusammen. Das ist etwas vollkommen anderes, als ein konventioneller Report macht.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Dem muss ich aber wiedersprechen.ralf.wenzel hat geschrieben: ↑30.11.2022 17:00Ich arbeite streng nach dem Prinzip "ich löse ein Problem im System nur einmal" und das geht mit lokalen Klassen nicht.
Klar geht das auch mit einer lokalen Klassen. Ich schrieb ja oben schon, dass man das beim Factory-Pattern nutzen kann. In get_instance() ist nur das Interface als Return angegeben. Ob die Methode dann eine Instanz einer lokalen oder Klasse oder einer globalen Klasse liefert ist doch egal. Somit ist das Problem an einer Stelle gelöst und kann überall* im System verwendet werden.
Klar kann man eine lokale Klasse dann nicht in globalen Klassen vererben. War manchmal will man das auch nicht, damit im System nicht Wildwuchs von 'zig Ableitungen entsteht. Alle Ableitung würden sich dann in der Factory befinden.
--
*Je nach Paketabhängigkeiten.
Ich versuche eigentlich immer Instanz-Methoden zu verwenden, da dies Sinn und Zweck von OO ist. Darüber hat sich mal ein anderer Entwickler beschwert, weil ich in meinem DAO nur mit Instanze-Methoden gearbeitet habe und lieber die die Methoden direkt (ohne Instanz) verwendet hätte. Damals noch als globale Klasse. Ich nutze das DAO z.B. dafür, dass ich die Datenzugriffschicht (ohne Logik) einfach mal komplett gegen eine DAO-Mock-Klasse austauschen kann, um damit Unit-Test laufen lassen zu können. Hier machen aber Statische Methoden keinen Sinn, da ich mir die Instanz auf ein Interface packe.sap_enthusiast hat geschrieben: ↑30.11.2022 13:28Wie steht ihr zu statischen bzw. Instanzmethoden? Ist es generell falsch, statische Kapselung zu bevorzugen?
Um nun dieser Fremdverwendung der DAO und damit den unbegründeten Beschwerden von anderen Entwickler bezüglich der statischen Methoden zu umgehen, hab ich das DAO als lokale Klasse angelegt. Und dann sogar mit lokalem Interface.
Zuletzt geändert von msfox am 01.12.2022 09:36, insgesamt 2-mal geändert.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
OK, auf so ne schräge Idee bin ich bisher nicht gekommen.... Aber so doof ist das gar nicht, dann ist die Factory von außen sichtbar, aber keiner fummelt mir so einfach an der Implementierung herum....
Ralf
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
msfox
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
9
Antw.
Antw.
5435
Views
Views
33
Antw.
Antw.
12107
Views
Views
Globale Klassen mit Zugriff auf Screen
von Danny Winn » 27.01.2017 18:15 • Verfasst in ABAP Objects®
von Danny Winn » 27.01.2017 18:15 • Verfasst in ABAP Objects®
3
Antw.
Antw.
2668
Views
Views
3
Antw.
Antw.
8442
Views
Views
Anzeige einer Klasse und/oder Methode (Globale Klassen)
von hfahrian » 02.04.2018 07:33 • Verfasst in ABAP® Core
von hfahrian » 02.04.2018 07:33 • Verfasst in ABAP® Core
8
Antw.
Antw.
9054
Views
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1030
vor 2 Tagen von DeathAndPain 4 / 1030
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1030
vor 2 Tagen von DeathAndPain 4 / 1030