Deklarationen: Tabellarisch oder nicht?

Re: Deklarationen: Tabellarisch oder nicht?

Daniel hat geschrieben:

ralf.wenzel hat geschrieben:Ich muss also gar nicht wissen, wie ein Fertigungsauftrag angelegt wird, wenn das in dem Objekt gekapselt ist, das auch die Daten dazu enthält.

Auch das ist nur ein Traum. Wer nicht weis wie ein PP-Auftrag
aufgebaut ist und worauf es ankommt der legt nur Datenmüll
an. Ohne Fachwissen geht es nicht.

Also, ich habe schon eine Reihe Serviceklassen angelegt, um zum Beispiel ein Amazon Versandlabel zu erzeugen (das ist ein ziemliches Gedöns mit Webservices und PI und Co.). Dazu muss der Aufrufer dann nicht mehr wissen, wie das gemacht wird, er muss nur die richtigen Parameter füllen. Was dann dahinter passiert, interessiert den anderen nicht.

Meine Erinnerung ist dunkel, aber für Fertigungsaufträge muss man eine bestimmte Sequenz von Funktionsbausteinen einhalten (die ich nicht gewusst hätte, hätte ich dich nicht fragen können). Solches Wissen kann man auch "wegprogrammieren", damit es alle haben. Und dann ist es eben schön, wenn das Coding nicht irgendwo steht, sondern im gleichen Modul wie die Daten, mit denen man arbeitet.

edit: Wir sind im Leben ständig von Objekten umgeben, zur Beschreibung realer Objekte aus dem wirklichen Leben gibt es nichts Eingängigeres als Objekte.

Daniel hat geschrieben:Und um Modular zu arbeiten braucht es kein OO.

Wenn man Daten und Coding *gemeinsam* als Modul sieht, dann stimmt der Satz nicht mehr. Und es geht eben nicht nur um Modularität, sondern auch um Abstraktion. Dann sieht man plötzlich "abstrakte Module", also eine Modularisierung, die ohne die Abstraktion gar nicht möglich wäre.

Und am Ende verknüpft man nur noch in sich abgeschlossene Einheiten / Module. So war es bei meinem vorherigen Kunden und auch bei meinem jetzigen. Man muss es halt durchziehen....

Daniel hat geschrieben:Genauso wie
man mit OO höchst unlesbares Coding erzeugen kann das nicht
wiederverwendbar ist weil die Schnittstellen unbrauchbar sind.

Richtig, wenn man es nicht kann.


Ralf

Re: Deklarationen: Tabellarisch oder nicht?

black_adept hat geschrieben:

ralf.wenzel hat geschrieben:Wenn man Daten und Coding *gemeinsam* als Modul sieht, dann stimmt der Satz nicht mehr. Und es geht eben nicht nur um Modularität, sondern auch um Abstraktion. Dann sieht man plötzlich "abstrakte Module", also eine Modularisierung, die ohne die Abstraktion gar nicht möglich wäre.

Wenn man von Modularisierung spricht sollte man sich auch an die gängige Definition hiervon halten. Und wie Daniel korrekt bemerkt -

Daniel hat geschrieben:Und um Modular zu arbeiten braucht es kein OO.

Und da wir vorhin bei Niklaus Wirth waren: Modula-2 ist keine OO-Sprache aber sehr wohl modular.

Das habe ich doch gar nicht bestritten, dass er grundsätzlich recht hat. Aber im ABAP OO gilt eben eine andere Art von Definition für "Modul", weil Daten und Coding eine Einheit bilden (darum ist eine Klasse sowohl ein Datentyp als auch eine Coding-Modularisierungseinheit), was im prozduralen ABAP eben nicht geht. Und wenn man diese Definition will, hat er eben nicht mehr recht.

Und ich schrieb, dass es eben auch um Abstraktion geht und die ist prozedural eben nur eingeschränkt möglich.


Ralf

Re: Deklarationen: Tabellarisch oder nicht?

Daniel hat geschrieben:Und um Modular zu arbeiten braucht es kein OO.

Das Problem ist, dass die meisten GAR nicht modular arbeiten, da wird das Rad jedesmal aufs Neue erfunden. Ein Beispiel unter Vielen:

Ich kann mich noch an einen Kunden erinnern, bei dem ich immer gesagt hab "wir müssen eigentlich die UI und die DB-Logik von der eigentlichen Funktion trennen". Da winken dann immer alle beim Kunden ab "brauchen wir nicht", "ist zu teuer", "Sie immer mit Ihrem theoretischen Kram für den Fall, dass mal was anderes kommt".

Wie gesagt: Es geht nicht um OO oder nicht - es geht einfach nur darum: Trennt man die unterschiedlichen Layer physisch voneinander? Das muss man dann natürlich konsistent machen (sprich: alle halten sich dran), also bedarf es einer Verständigung. Die ist nicht zu erreichen.

Der theoretische Fall scheint jetzt näherzurücken:

Neulich hab ich mit einem MA von denen telefoniert und der meinte "stell dir vor, hier hat einer den Knopf zur Prüfung der HANA-Kompatibilität gefunden, jetzt haben wir alle unendlich lange Listen mit Programmen, die wir korrigieren müssen, damit wir HANA-kompatibel sind". Abgesehen davon, dass die ja auch noch was anderes zu tun haben, sind die allein damit monatelang ausgelastet.

Darauf habe ich dann entgegnet: "Ihr müsst das nicht alles nur korrigieren, der Fachbereich muss jedes korrigierte Programm auch komplett neu testen, die haben ja auch sonst nix zu tun". Mit einer separaten DB-Schicht wäre das nicht passiert, weil man dann die Funktionen nicht anrühren muss - die funktionieren also nachher genauso wie vorher.... Ob die DB-Schicht korrekt arbeitet, kann der Entwickler allein testen, sogar automatisiert.

Dann meinte derjenige noch, dass die jetzt alle Fiori-Schulungen machen, da ist mir dann das Telefon fast aus der Hand gefallen, denn Fiori-fähig ist natürlich auch keine Anwendung. Die schreibt man komplett neu, weil man einen Report nicht aus Fiori heraus aufrufen kann, aber in dem Report, der das Selektionsbild enthält, ist natürlich auch die ganze DB- und Geschäftslogik. Das kriegt man ohne "neu schreiben" gar nicht wieder auseinander.

Es gibt auch superviel Entwicklerwissen, das nur im Kopf des Entwicklers steckt. Das ist falsch - es muss im SAP-System stecken, entweder im Coding oder in der Doku. Sonst hat man eine Transaktion, die keiner versteht (insbesondere wenn die total verschwurbelt programmiert wurde), die auch keiner richtig warten kann und wo jeder hofft "hoffentlich muss da keiner mehr ran".

Ehe ich zu meinem jetzigen Kunden ging, hatte ich ein Angebot eines Unternehmens, das praktisch bei mir um die Ecke lag. Als ich gesehen habe, wie die arbeiten, habe ich abgewunken und gesagt, dass ich mir ein solches Gefrickel nicht ohne Not ans Bein binde. Spaghettiprogramme ohne Dokumentation und Kommentare, wo man dann per Debugger raten darf, was das Teil überhaupt macht.

Das macht jetzt ein anderer Freiberufler aus HH.


Ralf

Re: Deklarationen: Tabellarisch oder nicht?

Daniel hat geschrieben:Das beweist aber nur daß du die dem SAP-System zugrunde liegende
Dynpro-Technik nicht verstanden hast. Auch diese beinhaltet eine
Art der Modularisierung. Wenn man UI, DB und Logik trennt muss
man das SAP-System neu programmieren.

Natürlich habe ich die Dynprotechnik verstanden. Aber ich kann nicht sagen "so, Dynpros sind jetzt zuende, ich möchte jetzt die Funktionen des Programms von einer anderen GUI aus bedienen (sei es ein Java-Portal, das man dafür programmiert hat - du erinnerst dich?).

Zum Neu-Programmieren: Genau das hat die SAP in weiten Teilen getan. Heißt S/4HANA. Und neueres Coding der SAP (z. B. EWM) ist deutlich modularisierter als altes.


Ralf

Nachtrag: Spätestens bei Table-Controls fand ich die Dynpro-Technik ganz furchtbar und extrem aufwendig. Da ist mir ein ALV-Control, für das ich im besten Fall nen Dreizeiler brauche, deutlich lieber.

Re: Deklarationen: Tabellarisch oder nicht?

ralf.wenzel hat geschrieben:Zum Neu-Programmieren: Genau das hat die SAP in weiten Teilen getan. Heißt S/4HANA. Und neueres Coding der SAP (z. B. EWM) ist deutlich modularisierter als altes.

Und was veranlasst dich dann anzunehmen daß man seine R/3-Programme
in S/4 einfach so (ohne Anpassung und ohne Testen) weiterverwenden kann?

Re: Deklarationen: Tabellarisch oder nicht?

Daniel hat geschrieben:Und was veranlasst dich dann anzunehmen daß man seine R/3-Programme
in S/4 einfach so (ohne Anpassung und ohne Testen) weiterverwenden kann?

Das ist ganz einfach zu erklären, da ich aber auf Metaphern stehe, wird es jetzt etwas wortreich:

Ich habe ein Programm mit drei "Knöpfen" (es sind Buttons, aber ich bin aus dem Pott, da sind das "Knöppe"). Einer davon erzeugt ein Formular, einer selektiert Daten und zeigt einen ALV etc.

Normalfall:

Man schreibt einen Report, der die Knöpfe anzeigt und über einen CASE sy-ucomm abfragt und die Funktion ausführt. Hast du SAPscript und willst Adobe PDF, änderst du das Programm und musst es komplett testen. Willst du eine weitere Funktion dazubasteln, musst du das Programm an mehreren Stellen erweitern und eben auch neu testen. Du erfindest das Rad jedesmal neu.

Besser:

Du teilst das Programm in zwei Teile: Den Dialogteil nennen wir Dialogcontroller, den Rest Applikationscontroller.

Der Dialogteil stellt die Knöpfe da. Wenn du einen Knopf drückst, meldet der Dialogcontroller an den Applikationscontroller "hey, der Knopf X wurde gedrückt" und der Applikationscontroller erzeugt führt die Funktion aus und meldet das Ergebnis an den Dialogcontroller zurück.

Wenn du jetzt SAPUI5 einführst, hast du einfach einen anderen Dialogcontroller. Die Funktion selbst ist ja von der UI unabhängig, also funktioniert die weiter.

NOCH Besser - mit OO:

Im OO ist ein Knopf eine Klasse, der eine bestimmte Schnittstelle implementiert. Das bedeutet: Weder Dialogcontroller noch Applikationscontroller WISSEN, was der Knopf genau macht. Der Dialogcontroller meldet "dieser Knopf hier wurde gedrückt" und übergibt den Knopf (genauer: die Schnittstellenimplementierung) an den Applikationscontroller. Der sagt dann nur noch dem Knopf "führe bitte mal deine Funktion aus", ohne zu wissen, was der überhaupt macht. Der Knopf selbst ist eine in sich geschlossene (und testbare!) Einheit, die man einfach in den Dialog hängt oder eben nicht.

Es gibt natürlich noch andere Funktionen, die vom Applikationscontroller selbst ausgeführt werden, aber gerade bei den Knöpfen ist das eben nicht nötig. Weil der Knopf WEISS, welche Funktion er ausführt (man übergibt ja mit der Schnittstelle auch das Coding, die Implementierung). Und das sind eben Dinge, die ohne OO nicht gehen. Du kannst an einen Funktionsbaustein Daten übergeben, aber eben kein Coding. Das musst du aber machen, weil jeder Knopf natürlich anderes Coding ausführt.

Das heißt auch: Brauchst du eine neue Funktion, schreibst du eine Klasse dafür, implementierst die Schnittstelle, die diese Klasse als Knopf identifiziert und das daraus entstehende Objekt registriert sich in der "Knopfleiste". Dann brauchst du weder Dialog- noch Applikationscontroller zu ändern.

Das ist jetzt eine vereinfachte Darstellung ohne Servicelayer und Datenbankabtrennung, aber das Prinzip dürfte klar sein: Man hat unterschiedliche Schichten, die voneinander unabhängig sind und über definierte Schnittstellen miteinander kommunizieren. Und darum kann ich jede Schicht austauschen.

Und dann ist eben egal, aus welcher UI die Anweisung kommt "mach mir mal bitte ein Formular". Es ist sogar egal, was für ein Formular das ist, weil das kann ich auch austauschen (Servicelayer).

Zum Datenbanklayer: Es erscheint aufwendig, wenn man die Anweisungen SELECT, UPDATE, etc. nicht in Programmen einsetzen darf. Stattdessen ruft man ein Unterprogramm (OO: Methode) in einem separaten Programm (OO: Klasse) auf, die diese Daten besorgt und zurückliefert. Im einfachsten Falle hat man dann eine Reihe von Programmen (Klassen), in der alle DB-Zugriffe gekapselt sind. Wenn S/4 kommt, schreibt man NUR diesen Teil neu, denn man hat ja definierte Schnittstellen: Eingabeparameter und Ausgabeparameter. Der Applikation kann im Grunde vollkommen egal sein, wo die Daten herkommen. Das Programm braucht die Daten, mehr nicht.

Edit: Und wenn man das nicht neu erfinden will, nimmt man BOPF, da ist das alles schon fertig. /Edit

Und was ich nicht ändere, muss ich eben auch nicht testen. Ich muss nur sicherstellen, dass die neue Lösung dieselben Daten liefert wie die alte. Und ob der Bestand, den ich abfrage, aus der MARC kommt oder ob die HANA-DB viel schneller den Bestand aus der MSEG errechnet, ist dem Programm völlig egal. Das braucht den Bestand, fertig.

Wenn ich (Dialogcontroller) meiner Frau (Applikationscontroller) sage "ich will jetzt ne Pizza mit Schinken und Pilzen!" ist mir auch egal, ob sie die bestellt oder selbst macht. Am Ende muss ne Pizza rauskommen. "Verbergen der Implementierung" im realen Leben - ich muss nicht die Frau wechseln, weil ich ne andere Pizza haben will.

Und ehe ich jetzt noch eine Mail schreibe, noch ein Insider zur ZC**N: Da habe ich haufenweise Bestandscoding aus der bestehenden, produktiv laufenden und funktionierenden Anwendung genommen und die Spezifika in Subklassen ausgelagert. Da ich bestehende Entwicklungsobjekte nicht angerührt habe, musste ich auch nicht testen, ob beim Erweitern was kaputtgegangen ist. Die Alternative wäre gewesen: Ein komplett neues Programm (Ohgott) oder man wurschtelt in dem alten herum mit dem Risiko, Fehler einzubauen, die sich dann im laufenden Betrieb auswirken (noch ohgotter).

Wie gesagt: Ich war lange kein Freund von OO - aber ich habe an praktischen Beispielen gelernt, welche Vorteile das hat, schon aufgrund des deutlich höheren Abstraktionsniveaus.


Ralf

Re: Deklarationen: Tabellarisch oder nicht?

Daniel hat geschrieben:

"Wenn S/4 kommt, schreibt man NUR diesen Teil neu,"

Da sieht man mal wieder wie grau alle Theorie ist.
Im S/4 sind einige Datenmodelle geändert, das passt
trotzdem nicht. Und ein SAP-System ist keine Pizzeria.
Die Objekte sind da ein klein wenig komplexer

Das Datenmodell dahinter ist eben völlig egal, das hatte ich beschrieben. Woher der Bestand kommt, den ich abfrage, ist mir egal. Die Applikation braucht den Bestand von Material X in Werk Y auf Lagerort Z. Wo die Daten herkommen, ist aus Sicht der Applikation irrelevant.

Und wenn S/4 kommt, dann werden die Daten eben anders selektiert, aber eben trotzdem bereitgestellt. Vom Datenbanklauer. Dann muss ich das Programm nicht ändern, weil sich das Datenmodell ändert.


Ralf *das leben ist eine pizza

Nachtrag: Ich hatte das in einem Projekt, ist gerade ein halbes Jahr her. Projekt fertig, alles fertig, alles getestet. Nun kommt der Anwender und sagt, er habe was in der Anforderung vergessen. Die Folge war: Das Datenmodell mussten wir komplett anpassen. Das haben wir gemacht, den DB-Layer (also genau EINE Methode) geändert und die Anwendung hat trotzdem funktioniert. Weil der Anwendung völlig egal ist, wo und in welcher Form die Daten gespeichert sind - sie arbeitet nur damit.