Wann verwendet man Forms (statt Functions)
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Hallo an Alle,
Über
Forms vs Functions fand ich folgendes:
funtion modules subroutines
1.they can be tested by itself 1.they cannot .
2.they can be remote enabled 2.they cannot .
3.they can handle exceptions 3.Only a few can handle.
4.they have to be maintained in 4.It is not necessary.
a function group.
Für mich alles +Punkte für Functions und ich frage mich wozu bzw. WANN ich denn dann Forms überhaupt noch verwenden sollte.
Eine Übersicht zu Methoden vs. Forms vs. Functions habe ich leider noch nicht gefunden. Auch dazu hätte ich gern noch ein paar informationen.
Im Grunde genommen ist Abap nicht so schwer wenn man schon programmiererfahrungen hat, nur ist es manchmal schwierig die unterschieder zwischen manchen befehlen herauszustellen die eine große gemeinsame schnittmenge haben und sich danach für den "besseren" im jeweiligen Fall zu entscheiden. Jedes Programm kann funktioniern, aber die verwendung von befehlen sollte doch mit dem richtigen hintergrundwissen gemacht werden.
Die bücher von SAPpress sind allesamt sehr gut geschrieben, doch fehlt mir meist die veranschaulichung von gemeinsamkeiten und wie gesagt allem unterschiede von verschiedenen Befehelen und deren Einsatz.
WEnn jemand da ein Tipp für Lektüre, Links, o.ä. hat bin ich super dankbar. Das würde mich für den Anfang sehr viel weiter bringen.
Viele Grüße RiG
Über
Forms vs Functions fand ich folgendes:
funtion modules subroutines
1.they can be tested by itself 1.they cannot .
2.they can be remote enabled 2.they cannot .
3.they can handle exceptions 3.Only a few can handle.
4.they have to be maintained in 4.It is not necessary.
a function group.
Für mich alles +Punkte für Functions und ich frage mich wozu bzw. WANN ich denn dann Forms überhaupt noch verwenden sollte.
Eine Übersicht zu Methoden vs. Forms vs. Functions habe ich leider noch nicht gefunden. Auch dazu hätte ich gern noch ein paar informationen.
Im Grunde genommen ist Abap nicht so schwer wenn man schon programmiererfahrungen hat, nur ist es manchmal schwierig die unterschieder zwischen manchen befehlen herauszustellen die eine große gemeinsame schnittmenge haben und sich danach für den "besseren" im jeweiligen Fall zu entscheiden. Jedes Programm kann funktioniern, aber die verwendung von befehlen sollte doch mit dem richtigen hintergrundwissen gemacht werden.
Die bücher von SAPpress sind allesamt sehr gut geschrieben, doch fehlt mir meist die veranschaulichung von gemeinsamkeiten und wie gesagt allem unterschiede von verschiedenen Befehelen und deren Einsatz.
WEnn jemand da ein Tipp für Lektüre, Links, o.ä. hat bin ich super dankbar. Das würde mich für den Anfang sehr viel weiter bringen.
Viele Grüße RiG
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Wenn du es dir ganz einfach machen willst stell dir Funktionen wie Modularisierungseinheiten vor die "public" definiert sind - sie können also von überall heraus aufgerufen werden.
Forms hingegen sind eher "private" Modularisierungseinheiten, die nur in dem Programmkontext aufgerufen werden, in dem sie definiert wurden.
Und genau so wie es Gründe gibt Methoden private oder public zu machen, wirst du ähnliche Argumentationen verwenden können um zu begründen warum du eine Form oder Funktion verwendest.
Forms hingegen sind eher "private" Modularisierungseinheiten, die nur in dem Programmkontext aufgerufen werden, in dem sie definiert wurden.
Und genau so wie es Gründe gibt Methoden private oder public zu machen, wirst du ähnliche Argumentationen verwenden können um zu begründen warum du eine Form oder Funktion verwendest.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
RIG
mmh, ja, ich verwende Forms, aber (noch) ohne Argumentation.black_adept hat geschrieben: Und genau so wie es Gründe gibt Methoden private oder public zu machen, wirst du ähnliche Argumentationen verwenden können um zu begründen warum du eine Form oder Funktion verwendest.
Ich meine zur Zeit benutze ich Forms wenn die Funktion zu speziell ist und nur in meinem Programm / Paket gebraucht wird.
Noch andere Beispiele bei denen Ihr Forms statt functions verwendet?
MfG RIG
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Immer wiederkehrende Aufgaben, die nur im Umfeld des Programms Sinn machen und die der Einfachheit halber auf globale Daten zugreifen sollen.
z.b. die (mehrfache) Ausgabe einer Zeile innerhalb eines LOOPs.
z.b. die (mehrfache) Ausgabe einer Zeile innerhalb eines LOOPs.
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 / 4089 / 127 /
940
)
»
Hi RIG,
ich mache es mal an einem Beispiel deutlich. Wenn eine neue Applikation entwickelt werden soll, kann man alles zugehörige Coding in ein Paket packen. Dort findet sich dann (hoffentlich) alles, was zu dieser Applikation gehört.
In dieser Applikation können nun sowohl FuBa als auch Reports sein.
Nun soll ich eine neue Funktionalität einbauen - z.B. eine Berechnung einer unendlich wichtigen Kennzahl.
Wenn diese Kennzahl in vielen Programmen angezeigt werden soll, so würde ich einen FuBa bauen ( oder eine statische Methode ), damit im Fall einer Änderung nur dieser FuBa angepasst werden muss und alle Programme die dieses Ergebnis verwenden gleich bleiben können.
Wenn diese Kennzahl hingegen nur in einem einzigen Report wirklich benötigt wird, so würde ich hierfür (ab einer hinreichenden Komplexität der Berechnung ) eine FORM verwenden. Dadurch wird die Berechnung vom Rest des Codings abgegrenzt und auch der Aufruf der FORM im Coding kann dann bei sinnvoller Namensgebung gleichzeitig als Kommentierung des Codes durchgehen.
Und noch eine private Meinung:
Das Auslagern von Funktionalitäten auf FuBa oder Klassen, die nur von einem einzigen Programm verwendet werden finde ich nicht so toll, da ich es recht gerne sehe, wenn ich in der Strukturübersicht eines Programms alle Funktionalitäten wiederfinde. Und bei einer sinnvollen Modularisierung des Programms inkl. Namesgebung sollte es beim Lesen/Ändern eines Programms recht einfach sein sich schon anhand dieser Strukturübersicht an die richtige Stelle zu hangeln.
ich mache es mal an einem Beispiel deutlich. Wenn eine neue Applikation entwickelt werden soll, kann man alles zugehörige Coding in ein Paket packen. Dort findet sich dann (hoffentlich) alles, was zu dieser Applikation gehört.
In dieser Applikation können nun sowohl FuBa als auch Reports sein.
Nun soll ich eine neue Funktionalität einbauen - z.B. eine Berechnung einer unendlich wichtigen Kennzahl.
Wenn diese Kennzahl in vielen Programmen angezeigt werden soll, so würde ich einen FuBa bauen ( oder eine statische Methode ), damit im Fall einer Änderung nur dieser FuBa angepasst werden muss und alle Programme die dieses Ergebnis verwenden gleich bleiben können.
Wenn diese Kennzahl hingegen nur in einem einzigen Report wirklich benötigt wird, so würde ich hierfür (ab einer hinreichenden Komplexität der Berechnung ) eine FORM verwenden. Dadurch wird die Berechnung vom Rest des Codings abgegrenzt und auch der Aufruf der FORM im Coding kann dann bei sinnvoller Namensgebung gleichzeitig als Kommentierung des Codes durchgehen.
Und noch eine private Meinung:
Das Auslagern von Funktionalitäten auf FuBa oder Klassen, die nur von einem einzigen Programm verwendet werden finde ich nicht so toll, da ich es recht gerne sehe, wenn ich in der Strukturübersicht eines Programms alle Funktionalitäten wiederfinde. Und bei einer sinnvollen Modularisierung des Programms inkl. Namesgebung sollte es beim Lesen/Ändern eines Programms recht einfach sein sich schon anhand dieser Strukturübersicht an die richtige Stelle zu hangeln.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
RIG
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Autsch! Sowas sehe ich gar nicht gern. Ordentliche Schnittstelle, nur lokale Felder, das garantiert, dass man eine Form auch problemlos kopieren kann. Ich nehme die auch gern, um Übersicht reinzukriegen. Z. B. hat jedes ALV-Anzeige-Programm eine Routine für die Listparameter. Da einige immer gleich sind, kopiere ich die Form in das neue Programm und passe sie nur noch an. das geht sauber nur dann, wenn man nicht auf Globals zugreift (die eben nicht überall gleich sind).a-dead-trousers hat geschrieben:auf globale Daten zugreifen
Gerade auch gemacht: Zwei Programme, die fast (!) das gleiche tun. Includes bauen, die die Forms beiden bereitstellen und fertig. Ändert sich was an der Logik, ändert man das in beiden Programmen gleichzeitig (Shared Coding). Geht sauber auch nur ohne Zugriff auf Globals.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
RIG hat geschrieben:Ich meine zur Zeit benutze ich Forms wenn die Funktion zu speziell ist und nur in meinem Programm / Paket gebraucht wird.
Dann machst du es doch genauso wie BlackAdapt es beschrieben hat.
FORMs -> "lokale" Funktion in Programmen/FuBas
FuBas -> "globale" Funktion, die von verschiedenen Stellen aus aufgerufen werden und so Funktionen wiederverwendbar kapseln
FORMs werden von SAP auch noch in der TA: VOFM für Kopier-/Datenübernahmefunktionen/Rechenformeln/Nachrichtenbedingungen verwendet. Manche UserExists sind ebenfalls als FORMs realisiert.
Gruß Hendrik
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Eigentlich verabscheue ich sowas selber, aber ich denke da immer mehr in Richtung Klassen:
Da definiert man doch auch nicht für jedes (private) Attribut in der (privaten) Methoden-Schnittstelle einen Parameter.
Gut, die Globalen Variablen/Formroutinen sind eigentlich "super-globals" die auch von fremden Programmen manipuliert/aufgerufen werden können, aber das ist ja eigentlich ein Relikt aus den "Urzeiten" von ABAP, dass mit ABAP-OO der Vergangenheit angehören sollte.
Aus dem Grund sehe ich die Formroutinen eigentlcih als das, für was sie eigentlich eingeführt worden sind: Modularisierungseinheiten die legal(!!!) auf den gesamten Adressraum des Programms zugreifen können.
Zum Thema Includes:
Wir haben in unserem System "Altlasten" wo auch so programmiert wurde und einige Includes sind in gut 100 Programmen in Verwendung. Ist immer wieder lustig das zu transportieren: Generierungszeit der abhängigen Programm > 30 min. inkl. massiger Kurzdumps wegen LOAD_PROGRAM_LOST.
lg ADT
Da definiert man doch auch nicht für jedes (private) Attribut in der (privaten) Methoden-Schnittstelle einen Parameter.
Gut, die Globalen Variablen/Formroutinen sind eigentlich "super-globals" die auch von fremden Programmen manipuliert/aufgerufen werden können, aber das ist ja eigentlich ein Relikt aus den "Urzeiten" von ABAP, dass mit ABAP-OO der Vergangenheit angehören sollte.
Aus dem Grund sehe ich die Formroutinen eigentlcih als das, für was sie eigentlich eingeführt worden sind: Modularisierungseinheiten die legal(!!!) auf den gesamten Adressraum des Programms zugreifen können.
Zum Thema Includes:
Wir haben in unserem System "Altlasten" wo auch so programmiert wurde und einige Includes sind in gut 100 Programmen in Verwendung. Ist immer wieder lustig das zu transportieren: Generierungszeit der abhängigen Programm > 30 min. inkl. massiger Kurzdumps wegen LOAD_PROGRAM_LOST.
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 / 3924 / 200 /
280
)
»
Richtig, wenn man SOWAS macht, muss man natürlich aufpassen - insbesondere bei Änderungen, die dann alle Programme betreffen. Aber bei zwei Rahmenprogrammen ist das vertretbar, glaube ich 
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
17
Antw.
Antw.
11290
Views
Views
3
Antw.
Antw.
1643
Views
Views
Vorgänge in die 'Zuletzt verwendet Liste' aufnehmen
von Kai999 » 19.07.2017 11:02 • Verfasst in ABAP® für Anfänger
von Kai999 » 19.07.2017 11:02 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
1469
Views
Views
Überprüfung Z-Felder in bestimmten Tabellen ob verwendet
von jspranz » 03.07.2006 16:02 • Verfasst in ABAP® Core
von jspranz » 03.07.2006 16:02 • Verfasst in ABAP® Core
17
Antw.
Antw.
1064
Views
Views
Eclipse - warum/wann verwendet ihr es [nicht]
von black_adept » 22.11.2024 13:07 • Verfasst in SAP - Allgemeines
von black_adept » 22.11.2024 13:07 • Verfasst in SAP - Allgemeines
1
Antw.
Antw.
1192
Views
Views
Mandantenübergreifendes Objekt wird nicht verwendet
von Gast » 19.12.2005 13:23 • Verfasst in ABAP® Core
von Gast » 19.12.2005 13:23 • Verfasst in ABAP® Core
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 / 1073
vor 2 Tagen von DeathAndPain 4 / 1073
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 / 1073
vor 2 Tagen von DeathAndPain 4 / 1073