FORM vs METHOD

Re: FORM vs METHOD

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

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

Re: FORM vs METHOD

Das ist das Problem....

Re: FORM vs METHOD

Das ist natürlich richtig, aber mehr als einen Klassenaufruf braucht man da auch nicht mehr.