Gründe für die Instanziierung und gegen statische Methoden

Gründe für die Instanziierung und gegen statische Methoden

Hallo ABAP-Freunde!
Wir möchten bei uns eine neue Software programmieren, wobei es hauptsächlich um eine Konverterfunktionalität zwischen Strukturen und Feldern eines Fremdsystems und dem SAP-System geht. Nachdem die Entscheidung fiel, das Ganze mit ABAP Objects zu lösen, gab es 2 Meinungsbilder. Die einen meinten man könne das Ganze in statischen Klassen mit statischen Methoden abbilden. Die andere Meinung (auch meine eigene) war eher, das man - wenn man schon OO verwendet - auch die Instanziierung verwenden sollte. Ich habe leider spontan nicht viele Vorteile der Instanziierung finden können, habe nun recherchiert und bin auf folgende Vorteile gestoßen:

• statische Methoden werden bei erstem Aufruf sofort in den internen Modus geladen und bleiben bis zum Ende des Programms dort (höherer Speicherverbrauch) - Objekte werden vom Garbage-Collector gelöscht, sofern kein Zeiger mehr auf sie zeigt
• mit Statischen Klassen ist keine Polymorphie möglich
• ABAP OO verbietet die Redifinition statischer Methoden
• der statische Konstruktor ist Parameterlos und kann keine Ausnahmen propagieren

Außer dem ersten Punkt, werden die 3 letzten keinen Nachteil im Sinne derer darstellen, die die statische Klasse favorisieren, da sie eigentlich "nur" eine Klasse als Funktionssammlung verschiedener Konvertermethoden sehen.

Habt ihr noch weitere Begründungen, warum die Instanziierung besser ist, oder ist es eigentlich legitim, dass man sich statische Klassen baut, um bestimmte Datenkonvertierungsroutinen etc. zu erzeugen? Wie ist Eure Meinung?

Vielen Dank im Voraus!

Re: Gründe für die Instanziierung und gegen statische Method

Hi!

Wenn es um "einfache" Konvertierungen geht, mach ich eigentlich alles mit statischen Methoden.
Vorallem wenn die Konvertierungen mehrmals und unabhängig von irgendwelchen "Umgebungsinformationen" ablaufen, ist es IMHO sinnvoller statische Methode zu verwenden.
Man darf nicht außer acht lassen, dass auch eine Objekt-Instanzierung Laufzeit benötigt und wie du schon richtig bemerkt hast, müssen statische Methode nur einmal in den Speicher geladen werden.

Leider kann ich dir jetzt aber weder zu einem noch zum anderen raten. Das ist wirklich eine Entscheidung die man aus der Erfahrung heraus treffen muss.

Ich würde es vielleicht so sagen:
Sobald eine Methode viele Eingabeparameter besitzt und im Coding kommen ein Haufen Fallunterscheidungen ala "Par1 und Par2 sind gesetzt führe X aus" sollte man sich überlegen ob man das Ganze nicht besser "objektifizieren" sollte.
Auch wenn eine bestimmte Abfolge von Methoden immer wieder auftritt und das abhängig von bestimmten Variablen, dann wäre es ratsam das Coding in Objekten zu kapseln.

Vielleicht gibts ja noch weitere Beispiele von den anderen Foren-Teilnehmern, wann man statische Methoden einsetzen sollte und wann nicht.

Für den Anfang, auch wenn ihr euch noch in ABAP OO einarbeiten müsst, würde ich den strengen OO Weg einschlagen. Selbst bei reinen Konvertierungesroutinen lassen sich Objekte modelieren. Außerdem ist das dann eine Gute Übung um für die OO Programmierung fit zu werden.

lg ADT

Re: Gründe für die Instanziierung und gegen statische Method

Danke soweit!

a-dead-trousers hat geschrieben:Man darf nicht außer acht lassen, dass auch eine Objekt-Instanzierung Laufzeit benötigt und wie du schon richtig bemerkt hast, müssen statische Methode nur einmal in den Speicher geladen werden.

Ich kann alles nachvollziehen nur o.g. kann man auch als Nachteil sehen: Läuft das Programm länger und ich habe eine sehr große statische Klasse mit vielen Methoden, so bleibt diese komplett bis zum Programmende im internen Modus geladen und benötigt ja auch Arbeitsspeicher. Ein Objekt belegt diesen nur so lange, wie ich es benötige.
Das mit der Instanzierung stimmt natürlich auch wieder...muss man abwägen.

Ich schreib das nur nochmal, damit der Thread auch mal beim Suchen vollständig bleibt

Wenn man alles schön mit OO macht, müsste man sowieso anders vorgehen, da - diesen klugen Satz habe ich hier gelesen - Klassen um Daten modelliert werden und nicht als Funktionssammlung.

Ich freue mich auf weitere Ideen, evtl. gibts auch Tipps wie man bei anderen diese Blockade und Ablehnungshaltung löst.

Re: Gründe für die Instanziierung und gegen statische Method

black_adept hat geschrieben:Aber die Anmerkung von Ralf bzgl. Funktionsgruppen ist nicht von der Hand zu weisen, zumal du in deinem Originalposting von Konvertierungen zw. Fremd- und SAP-System gesprochen hast. Und nur FuBa sind RFC-fähig.

Ja, aber man kann trotzdem das Coding in einer Klasse schreiben und im RFC-Fuba nur den Aufruf machen.

Hab schon öfters sowas gemacht: Ich rufe die Methode einer Klasse auf. Wenn als Parameter eine RFC Destination mitgegeben wird, dann wird ein Fuba im Fremdsystem aufgerufen, der meine Methode mit denselben Parametern im Zielsystem aufruft.

lg ADT

Re: Gründe für die Instanziierung und gegen statische Method

Vielen Dank so weit für die Einblicke!
Also ich bin mittlerweile wohl auch der Meinung, dass wenn es um Methoden geht, die wirklich auf granularer Ebene arbeiten, statische Methoden nichts verwerfliches sind. Ein Beispiel dafür ist: Eingabe X = Ausgabe Y, z.B. mache aus JahrMonatTag --> TagMonatJahr. Oder eben die von black_adept angesprochene Klasse cl_bcs_convert.
Sobald es aber um mehrere Felder oder gar ganze Strukturen geht, die wirklich auch ein Objekt abbilden (z.B. wandle die Struktur eines Geschäftspartners aus dem Fremdsystem in das SAP-System um), macht es glaub ich mehr Sinn, diese "Schicht darüber" dann auch mit Objekten zu machen (in dem o.g. Fall mit einem Geschäftspartnerobjekt). Das Objekt selbst kann ja dann - wenn es um die einzelnen Felder geht - u.a. auf die statischen Methoden einer Utility-Klasse zurück greifen.
Grüße!