Klassen als Funktionsbaustein ersatz / Memory

[Maja967]

Hallo,

ich verwende eine Klasse als Ersatz für Funktionsbausteine bzw Funktionspool, dh in eine Klasse lege ich statische Methoden an, die die Rolle von Funktionsbausteinen übernehmen.
(Warum-> handling aus meiner Sicht einfacher). Hierbei geht es nicht um OO-Programmierung sondern um prozedurales Programmieren !

Ich würde nun gerne wissen wie eine statische interne Tabelle memory-mäßig zu "händlen" ist.

ein Programm verwendet Methoden aus 2 unterschiedlichen Klassen

KLasse zcl_1 hat eine interne Tabelle it_1 die durch eine methode zcl_1->befuellen ... ( ) befüllt wird.

aus der Klasse zcl_2 greife ich nun via Methode zcl_1->get auf diese Tabelle zu. In der Methode sieht das in etwa so aus:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1.          loop at zcl_1=>it_1 assigning <fs>
2.             ...........
3.          endloop.
4.  

GeSHi ©

Die interne Tabelle aus ZCL_1 "gehöhrt" doch sicherlich zum "Speicherbereich" des Programms in der sie verwendet wird. Und dieser Speicherbereich gehört doch dann auch zum Prozess in dem das Programm läuft. (falls das Programm gleichzeitig läuft wird die interne Tabelle durch den anderen Prozess nicht überbügelt).

*grmpf .... oder sollte ich diese vorgehensweise canceln und die Klasse zcl_1 mit get/set auf diese interne statische Tabelle ausstatten ... ? meine bedenken sind hier -> Laufzeitverlängerung wegen Methoden-Call

[Ilja583]

Ich glaube das ist mehr eine Philosophiefrage.
Falls du auf die Laufzeit achten musst ist deine aktuelle Version gut. Und persönlich würde das wahrscheinlich auch so umsetzen wie du es gemacht hast.
Wenn du allerdings "dichter" an der Funktionalität einer Funktionsgruppe sein möchtest solltest du die stat. Tabelle tatsächlich auf "private" setzen und nur über explizite Methoden ansprechbar machen. Denn das entspricht etwa dem, dass nur Funktionen derselben Funktionsgruppe auf deren globale Daten zugreifen können

[Maja967]

- da die Methode ca täglich 2-3 Millionen mal durchlaufen wird möchte ich auf die Laufzeit achten.
- Funktionsgruppe: Die Zugriffe auf die Klassen kann ich per Konvention regeln (Klasse wird nur In-House verwendet), deshalb kann ich das entwas "entspannter" betrachten.

- wäre es sinnvoll Vererbung zu verwenden .... ?

gegeben:
ZCL_1 (Übergreifende Funktionen)
ZCL_2 (Fachl. Logik1)
ZCL_3 (Fachl. Logik2)

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. Oberklasse:                          zcl_1
2.                                       .
3.                               ....................
4.                               .                  .
5. Unterklassen                zcl_2             zcl_3
6.  
7.  

GeSHi ©

- somit würde zumindest erkenntlich werden das die 3 Klassen zusammenhängen ...
aber ob es dadurch langsamer wird weiß nun auch nicht, ich vermute ja, da der Interpreter
"nachschlagen" muß wo er den die interne Tabelle findet ...

[Ilja583]

Hallo cut1,

so wie du es beschreibst nimm ruhig die Vererbung.
Dass es spürbar langsamer wird nehme ich nicht an - sowohl bei Verwendung der Vererbung als auch ohne werden irgendwann die beiden Klassen geladen werden müssen und ab dem Moment "weiß der Interpreter wo er suchen muss".
Außerdem hätte es den Vorteil, dass du die interne Tabelle auf "protected" stellen kannst. Denn das entspricht m.E. dem was du damit vor hast.

[Maja967]

soderle, jetzt hab ich nur noch Bauchscherzen mit der Aufteilung dieser Klassen auf Pakete....

falls ich die Übergreifenden Sachen di in ZCL_1 stecken in das Paket P_1 stecke
die fachliche Logik in der Klasse zcl_2 in Paket P_2 stecke
die fachliche Logik in der Klasse zcl_3 in Paket P_3 stecke

dann hätte ich ein "schlechtes" Design ? aber `ne Ordnung hinsichtlich wo steckt was ...
was meinst Du ?

man sollte vielleicht mal so ein Grundlagen FAQ für das Paketkonzept beginnne ... würde das ja machen aber habe leider keine Erfahrungen damit ....

[Ilja583]

Hallo cut1,

ich glaube du machst dir einfach zu viele Gedanken hier.
Sowohl mittels des Klassen/Vererbungsgedankens als auch mittels Paketbildung kann man inhaltlich zusammengehörige Sachen gruppieren. Dass du dir Gedanken darüber machst wie du deine Sachen gruppieren möchtest ist schon mehr als ich üblicherweise in meinen Projekten sehe.
Nimm doch einfach den Ansatz der dir am meisten behagt. Ich schätze du kannst sowohl für die eine als auch die andere Vorgehensweise Gründe finden.
Ansonsten schau mal nach, ob es irgendwelche Entwicklungsrichtlinien gibt, die du zu beachten hast. Oder frage Kollegen wo/wie sie suchen würden wenn sie zwar wissen das "etwas existiert" aber nicht wissen wo. Und dann leg es so ab dass die meisten Leute es schnell finden.

[Maja967]

@black_adept

thx für die Blumen, denke das die ORGA der Entwicklungsobjekte wichtiger Punkt ist.
- Vermeidung Fehl- oder Doppelentwicklung
- Anwendungslandschaft klarer
- Anpassung an Anwendungen mit weniger Bauchschmerzen
- etc

Leider habe ich da noch nicht so die richtige Literatur für mich (praxisrelevant) gefunden ...

dann wohl try and error ... *g

schönes WE