Fuba oder Methode

Re: Fuba oder Methode

Er hat "Jehova" gesagt

Grundsätzlich ist eine Methode etwas vollkommen anderes als ein Funktionsbaustein, auch wenn die Funktionalität bei einer statischen Methode in einer Klasse nicht unähnlich ist. In aller Regel ist die Struktur einer Methode auch anders als die eines Funktionsbausteins. Eine Methode soll genau EINE Sache atomar durchführen, Funktionsbausteine sind meistens ziemliche Monolithen.

Also, bei jeder statischen Methode frage ich mich, warum die statisch ist, weil einem das viele Möglichkeiten nimmt. Der ganze Vererbungskram z. B. beruht auf einer Instanz, die vorliegt.

Zudem ist (wenn wir uns vom Statischen jetzt mal lösen) ein Objekt immer die Gemeinsamkeit von Coding und Zustand (Attribute), so kann ich eine Klasse / ein Interface an eine Methode übergeben und in dieser Methode eine Methode der übergebenen Klasse / Interface ausführen. Ein Beispiel dafür hab ich hier mal beschrieben. Das geht bei Funktionsbausteinen nicht so einfach, einem Funktionsbaustein das Coding einer Funktionsgruppe zu übergeben, damit dann einer der darin enthaltenen Funktionsbausteine ausgeführt wird.

Und auch, wenn es Leute gibt, die behaupten, Polymorphie führe zu unlesbarem Coding, kann ich der viel abgewinnen -- weil ein Coding auf einer höheren Abstraktionsebene zumeist nur so gut ist, wie seine Dokumentation. Und das ist vielen Entwicklern dann schon zu anstrengend. Natürlich bedeutet Polymorphie abstrakteres Coding, aber die Gegenmaßnahme kann nicht sein, auf die Vorteile der Polymorphie zu verzichten, sondern gescheit zu dokumentieren! Wir verzichten ja auch nicht auf Computer, weil die meisten nicht verstehen, wie sie funktionieren. Und diese Abstraktionsebene hat halt eine Menge Möglichkeiten, die ich sonst mühsam selbst "nachprogrammieren" müsste, um meine Ziele zu erreichen.

Methoden haben Vorteile, die andere hier als Nachteile sehen - zum Beispiel kann man das Ergebnis einer funktionalen Methode direkt weiterverwenden, ohne eine Variable dafür zu brauchen. Ein Funktionsbaustein zerschneidet einem immer das Coding, was ich zum Beispiel ziemlich furchtbar finde. Für andere ist die "Geschwätzigkeit" von ABAP ein Feature. Mich lenkt eben diese "Geschwätzigkeit" vom eigentlichen Kernproblem ab.

Außerdem finde ich gut, dass Typfehler bei Methodenparametern schon von der Syntaxprüfung angemeckert werden und nicht erst durch einen Dump zur Laufzeit. Aber die Diskussion hatten wir hier auch schon....

Ich hab gerade mal überlegt - einen Vorteil einer Funktionsgruppe zu einer Klasse könnte ich jetzt nicht nennen, abgesehen von RFC. Vielleicht fällt einem anderen ein Vorteil ein.


Ralf *schreibt FuBas nur für RFC und bestenfalls als Träger eines Dynpros

Re: Fuba oder Methode

Naja, man kann mit FuBas halbwegs ordentlich parallelisieren im gegensatz zum OO... oder zumindest finde ich dazu nichts ordenltiches.
Ansonsten hat Ralf alles wissenswerte gesagt. Insbesondere der Funktionale Aufruf von Methoden ist unschlagbar, weil ich es meiner Meinung nach auch die Lesbarkeit immens erhöht.

Also am Besten immer Methoden ( und umso granularer desto besser - und am besten noch instanzgebunden ) erstellen.

Re: Fuba oder Methode

Aber wenn ich z.b. mehrere Berechnungsfunktionen brauche, dann kann ich doch genauso:

methode calc_x
methode calc_y
methode calc_z

in einer Klasse z.B. Calc_Function haben, die diese bereitstellt anstatt Fubas zu erstellen.

Um halt die genannten Vorteile nutzen zu können .

Re: Fuba oder Methode

Re: Fuba oder Methode

black_adept hat geschrieben: Ralf hat ja schon seinen durchaus wohlschmeckenden Senf beigesteuert - aber das Problem bei Ralf ist, dass er nicht mit normalen Usern arbeitet, die noch eine prähistorische Ausgabe via SAPGUI verwenden und damit Dynpros benötigen.FuBas oder Funktionsgruppen sind also schon mal dann nützlich, wenn du irgendwas mit Dynproausgaben machen willst

Ja so einer bin ich

Re: Fuba oder Methode

ralf.wenzel hat geschrieben: Und User, die heute mit SAPGUI arbeiten, wollen morgen vllt. etwas anderes haben, da lohnt es sich schon, zu kapseln und möglichst viel möglichst generisch zu machen.

Habe ich diese Woche schon mal erwähnt - Kosten/Nutzen-Relation.
Und nach dem was ich von SAP gehört habe bzgl. Unterstützung von der guten alten SAPGUI ( bzw. es wurde ja mal gesagt, dass dies ein auslaufendes Modell sei ) und von einigen Usern, die die Haptik der GUI einfach besser finden als das was SAP gerade so pusht halte ich die guten alten Dynpros immer noch für ein veritables Ausgabemedium.

ralf.wenzel hat geschrieben:... weil das Konstrukt schon arg schräg ist und so die meisten Entwickler sich mit diesen "Komisch-Heiten" nicht auseinandersetzen müssen.

Kann ich nicht nachvollziehen. So ein Dynpro ist doch ziemlich simpel gestrickt. Eigentlich wäre das ein Paradebeispiel für Objektorientierung, wenn man die Dynproelemente als solche ansteuern könnte statt nur über die LOOP AT SCREEN-Methodik. Nur dass sich SAP gescheut hat das mal auf Vordermann zu bringen und so operabel zu halten wie z.B. in Excel oder Word oder wie die Java-Swingklassen. Aber nachdem die Gui zum Aussterben verurteilt wurde hat man nix mehr reingesteckt und versteckt sich seitdem hinter der Aussage, dass Dinos nicht weiterentwickelt werden, ohne mal auf Anwender zu hören, ob die das überhaupt wollen. ( Irgendwie erinnert mich das an die Aussage, dass Batch-Input sich bald überholt hat, da es ja für alles BAPIs geben wird. Irgendwie hält sich dieser Zombie aber immer noch... )

Re: Fuba oder Methode

Nägel schlägt man mit einem Hammer ein,
Bretter werden mit einer Säge zerteilt...

Es gibt für verschiedene Anwendungen verschiedene
Werkzeuge. Und das ist ja auch sinnvoll.

Im Übrigen sind Browser noch wesentlich anfälliger für
jede Form von Missbrauch als Windows und SAPGUI.