FORM vs METHOD

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
8 Beiträge • Seite 1 von 1
8 Beiträge Seite 1 von 1

FORM vs METHOD

Beitrag von Dyrdek (Specialist / 306 / 30 / 0 ) »
Hallo zusammen,

Ich hab mich grad über einige SAP Grundlagen informiert und bin auf eine Definition von FORM bzw. Unterprogrammen geraten.
Dort steht aber das FORM in neuen Programmen nicht mehr verwendet werden soll, sondern METHOD.
Da stellen sich bei mir als Anfänger zwei fragen.

a) Wo liegt der Unterschied zwischen den beiden Optionen?
b) (Ergibt sich vielleicht aus Antwort für a) Wieso keine FORMs mehr?

Habe leider gerade keinen direkten Vergleich online gefunden, daher wollte ich mal hier nachfragen ob jemand einen kleinen Überblick geben kann.


Gruß

Dominic

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: FORM vs METHOD

Beitrag von wreichelt (Top Expert / 1031 / 29 / 188 ) »
Hallo,

ich glaube nicht dass FORM verschwinden wird, dazu wird es in Standardprogrammen noch viel zu häufig verwendet.
METHOD kommt aus der OO-Programmierung und SAP möchte halt das das in Zukunft verwendet wird.

Es gibt ja auch noch die Funktionsbsusteine CALL als dritte oder weitere Form für Unterprogramme.

Gruß
Wolfgang

P.S.: Ich verwende FORM weiter so wie in Unternehmen auch noch SAPSCRIPT-Formulare gibt

Re: FORM vs METHOD

Beitrag von Barney (Specialist / 104 / 20 / 9 ) »
Ich verwende auch noch FORM-Routinen, so lange ich weiß, dass ich diese nur innerhalb meines Programms benötige. Sobald ich eine Logik entwickle, die genereller einsetzbar ist und die in verschiedenen Programmen oder Exits verwendet werden kann (z.B. ermittle alle HU's aus einer Lieferung aus einer Umlagerungsbestellung), dann nutze ich eine statische Methode, was dem Wesen nach ja einem Funktionsbaustein entspricht.

Tot ziens
Barney

Re: FORM vs METHOD

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Grundsätzlich muss man zwischen OO und prozeduraler Programmierung unterscheiden. OO eignet sich eigentlich sehr gut, um Objekte der realen Welt zu beschreiben. Das liegt im Konzept begründet, was dazu führt, dass man deutlich weniger technisch denken muss als in der prozeduralen Programmierung. Man hat es halt mit einer Rechnung zu tun, die Attribute und Methoden hat, die genau für diese Art Beleg gelten. Und wenn eine Rechnung gebucht wird, dann muss man das nicht x mal neu programmieren, sondern es gibt eine Methode dafür, die an der Rechnung "klebt". Das nur vorab.

Ich verwende FORM überhaupt gar nicht mehr, wenn mir der Kunde das erlaubt. Die komplette Businesslogik liegt bei mir in Klassen, was man öfter braucht, in Serviceklassen. Mein jetziger Kunde verbietet duplikatives Coding und leistet sich eine QS, bei der das auch auffällt. Jedes Programm wird auditiert, ehe es ins Produktivsystem geht und wird duplikatives Coding erkannt, kriegt der Entwickler sein Programm wieder auf den Tisch mit der Anweisung "Serviceklasse schreiben". Das ist eine Arbeitsweise, die mir sehr entgegenkommt, die man aber fast nirgends auch nur im Ansatz durchgesetzt bekommt. Hier leistet man sich das, weil die Entwicklertruppe praktisch komplett aus der Produktentwicklung kommt (die haben also Standard-Add-Ons für SAP entwickelt, die von x Kunden gekauft wurden).

Welchen Vorteil hat das? Kein Mensch muss WISSEN, wie irgendwelche Prozesse bei dem Kunden umgesetzt werden, weil es dafür bereits gekapselte Klassen gibt, die das machen. Die ruft man einfach auf, weil man weiß, dass sie funktionieren. Gerade da, wo man sequentiell eine Folge von Funktionsbausteinen der SAP aufrufen muss, die auch auf bestimmte Weise mit festen Parametern versorgt werden müssen, lohnt es sich, das zu kapseln. Ich glaube, ich hatte das mal beim Anlegen von PP-Aufträgen. Da hatte ich jemanden gegenübersitzen, der mir sagen konnte, wie das geht. Ist der nicht mehr da, hat der Urlaub oder ist der krank, steht man da und weiß es eben nicht, wenn man sich im PP nicht wirklich auskennt. Ist das gekapselt, wird das "Voodoo" von der Klasse übernommen, die hoffentlich eine F1 Doku hat und der man nur das übergeben muss, was wirklich notwendig ist.

Beispiel: Ich schreibe einen Report, der besteht nur noch aus den Selektionsbildereignissen und Aufrufen von Methoden in globalen Klassen (schön aufgeteilt in Controller- und Model-Klassen). Der Vorteil ist, dass ich so die GUI schön gekapselt habe und wenn wir auf SAPUI5 umsteigen (damit ist bald zu rechnen), ändere ich nur die GUI und die Businesslogik muss nicht geändert und daher (das ist fast noch wichtiger) auch nicht getestet werden. Genauso die Datenbankzugriffe: Alle gekapselt in einer eigenen Schicht, SELECTs und UPDATEs sind hier explizit verboten, das kriegt man nicht produktivgesetzt. Wechselt man auf HANA oder sonstwas, schreibt man nur die Klassen um, die auf die DB zugreifen. Das Programm an sich muss man nichtmal testen. Und für Unit-Tests kann man die Datenbankzugriffe sogar mocken, wenn man das will.

Gegenbeispiel: Ich komme gerade von einem Kunden, der praktisch alles monolithisch runterprogrammiert hat. Um es mal krass zu sagen: Wenn die auf HANA oder S/HANA oder SAPUI5 umsteigen wollen, werfen die ihr komplettes System weg, weil das ganze Coding so aufgebaut ist, dass man die Programme komplett neu schreiben muss. Und selbst dann, wenn die Änderungen nur minimal sind, muss man alles neu testen. Wenn wir vorsichtig schätzen und sagen, da stecken 50 Mannjahre nur an Entwicklung drin, weiß man, welche Werte da weggeworfen werden. Eine UI zu schreiben oder die DB-Zugriffe umzuschreiben, ist im Verhältnis deutlich weniger aufwendig. Es ist sogar interessant, wie viele SELECTs man immer wieder braucht - bzw. andersrum: Wie wenig unterschiedliche SELECTs man letztlich im System hat (man sieht sie ja auf einen Blick).

Bei Formularen ist es so, dass ich unterscheide. SAPscript verwende ich für "modernes Reporting", wenn es also darum geht, eine Sammlung von Daten zu drucken, die im Dynpro auf verschiedene ALVs verteilt sind oder so. Der Grund. warum ich das nutze, ist der geringe Overhead, den eine Formularerzeugung produziert, solange das Formular eben eine gewisse Komplexität nicht überschreitet.

Wirkliche, richtige Formulare (Rechnungen, Bestellungen, etc.) mache ich am liebsten als Adobe PDF. Wenn ich mir vorstelle, wie das früher war, wenn man MEDRUCK-Kopien an die Kundenwünsche angepasst hat.... Grausig. Klar, Formulare bauen macht auch mit Adobe PDF keinen wirklichen Spaß, aber SAPscript vermeide ich dann doch, wo immer es geht.



Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: FORM vs METHOD

Beitrag von Dyrdek (Specialist / 306 / 30 / 0 ) »
Ok vielen dank für eure Antworten :) Glaube habe jetzt einen Überblick bekommen wo die Unterschiede liegen.
War nur in dem Artikel den ich gelesen hatte irritiert, dass Form "nicht mehr verwendet werden sollen".
In meinem ehemaligen Betrieb wurde diese uns noch beigebracht...

Vielen Dank und ein schönes Wochenenden allen zusammen! ;)

Re: FORM vs METHOD

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Das ist das Problem....
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: FORM vs METHOD

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Ich versuche zwar auch auf Formroutinen zu verzichten- aber es gibt diverse Stellen im SAP, wo man weiterhin nicht auf solche verzichten kann.
Beispiele:
  • SD oder PP: Hier werden im Customizing zum Nachrichtendruck Einstiegsprogramm und -formroutine benötigt
  • FI: Validierung oder Substitutionen arbeiten mit FORMS
  • SD: Fast alles was man in der VOFM findet läuft noch hier drüber
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: FORM vs METHOD

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Das ist natürlich richtig, aber mehr als einen Klassenaufruf braucht man da auch nicht mehr.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Seite 1 von 1

Vergleichbare Themen

3
Antw.
2144
Views
method changing
von kostonstyle » 05.08.2008 10:28 • Verfasst in ABAP® für Anfänger
2
Antw.
117
Views
method INTERNAL_ASSERT ????
von Anfänger » 20.12.2023 16:27 • Verfasst in ABAP® für Anfänger
3
Antw.
1499
Views
METHOD handle_user_command
von SAP_ENTWICKLER » 19.09.2013 09:38 • Verfasst in ABAP® Core
27
Antw.
1753
Views
Method für die Durchschnittsberechnung
von msentaburlar » 12.01.2020 15:18 • Verfasst in ABAP® für Anfänger
0
Antw.
1292
Views
Access Method 'G'
von slim » 02.03.2007 11:41 • Verfasst in Web Application Server

Ü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

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.