ABAP: technique de programmation

[l_cauchy]

Bonjour Tout le monde,
J'espère que vous allez bien.

Mon post concerne la programmation ABAP; Au fait j'aimerai savoir s'il existe des techniques de programmation en ABAP . C'est à dire des façons de coder, d'organiser son code, de la rendre maintenable; histoire de ne pas coder n'importe comment.

Comme en JAVA, On peut organiser nos projet en package, en C/C++ nous avons les includes;

Juste j'aimerai savoir si vous en connaissez des techniques du même genre en ABAP; merci de m'en faire parvenir.

je rappelle je suis débutant en programmation ABAP.

Merci d'avance.

[Celdrøn]

Salut,

Dans SAP aussi t'as des packages qui permettent de ranger les programmes selon certains critères comme le module.

Il est fort probable que des packages spécifiques aient été créés sur ton système, donc il faut que tu demandes lequel est le plus approprié.

Sinon, pour organiser son code, surtout s'il est conséquent, tu peux utiliser des Includes.
Une codification simple peut permettre de les distinguer facilement :
- ZPROG_TOP : Le TOP sera la déclaration des données globales
- ZPROG_SCR : Ça c'est l'écran de sélection mais certains préfèrent déclarer les écrans de séléction dans le TOP
- ZPROG_O01 : Modules du PBO (pour programmes avec Écran type dynpro)
- ZPROG_I01 : Modules du PAI (pour programmes avec Écran type dynpro)
- ZPROG_LCL : Pour les classes déclarées dans ton programme
- ZPROG_F01 : Pour déclarer les routines, s'il y en a trop, on peut faire un F02, F03, etc.

Voila à titre d'exemple ceux que j'utilise habituellement... voire tout le temps.

[l_cauchy]

Merci Celdron pour votre réponse, vous venez de m'éclaircir l'esprit.
Concernant les packages, puis je créer mes propres packages ou ils sont créés par défaut?
Cdt.

[Celdrøn]

Alors attention, on ne parle pas de package dans SAP comme on parle de package en Java.

Si le package en Java peut-être propre à un développement, dans SAP c'est un espace de travail partagé contenant programmes, fonctions, tables, etc. créés par toi et d'autres. C'est comme une allée de bibliothèque regroupant des ouvrages sur le même thème donc on ne créé pas de package au bon vouloir.

Le package t'es demandé lors du premier enregistrement de ton programme juste avant de te demander l'ordre de transport, sauf si t'as sélectionné le package pour les objets locaux.

Comme j'ai dit, un package peut servir à regrouper tout objet appartenant au même module ou au même projet.
Donc tu peux avoir un package ZSD (package pour programme SD spécifiques), ZMM (idem pour MM), mais également ZPROJET (Projet en cours), ZPROJET2 (Nouveau projet qui démarre), etc.
Donc il faut que tu te renseignes auprès de ton responsable pour savoir ceux existant et savoir si la création d'un nouveau est nécessaire.

Les packages par défaut sont les packages standards, donc non-utilisables. Donc si des développements spécifiques ont déjà été faits, alors t'en as forcement au moins un de créé.

[l_cauchy]

Merci, j'ai bien saisi la notion de package en ABAP maintennant.

[sandraros]

Bien sûr, si tu t'y connais en orienté objet, et que tu crées une application un tantinet complexe qui se prête aux classes, alors utilise-les. Pour les choses assez simples, l'objet devient contre-productif par rapport au procédural.

[l_cauchy]

Oui Sandraros, je m'y connais en Orienté Objet et l'application est un peu gigantesque, donc j'avais pensé à coder un peu de la même manière que je faisais en JAVA et du coût ce qui me vient à l'esprit c'est d'utiliser le design pattern MVC. Maintenant j'aimerai savoir serait il facile d'utiliser le MVC en ABAP ? et qu'en est il pour le ABAP OO ?

[Celdrøn]

Oula, le MVC carrément?

Tu vas en faire suicider plus d'un si on doit reprendre ton travail.

Le MVC n'est pas évident à comprendre, et il faut aussi penser que les développeur ABAP viennent de plusieurs horizons, et n'ont pas forcement eu une formation en développement.

Je trouve cela risqué d'utiliser les modèles de conception. J'ai déjà vu des personnes se casser les dents juste avec une seule classe, et ce n'était qu'un ALV, alors bon.

[txupi]

Pour rajouter mon grain de sel :

Quand je code je sépare mes requêtes du reste du code.
Je les mets dans un INCLUDE à part. Dedans il n'y a que des routines avec des requêtes. En entrer je passe les paramètres de sélection et en sortie je récupère le subrc ainsi que ce que je voulais récupérer. Chacune de ces routines est préfixé de la même façon.

Je fais pareil avec tout ce qui concerne les affichages. Par exemple l'affichage d'un message d'erreur ou d'un alv. Les routines concernées sont dans un INCLUDE à part et sont préfixées autrement.

De ce fait, je trouve que le code général est quand même plus structuré que de tout laissé dans le même endroit.

[beuzy]

J'avais tendance à faire ça aussi mais un audit SAP nous a remonté qu'on avait trop d'objets spécifiques à cause de tous ces includes

[txupi]

Ah bon? Vu que je le fais sur des programmes pas énormes encore, peut être que ça pose pas de problème.

[Celdrøn]

Que ce soit des programmes énormes ou non, là n'est pas le problème.
C'est plus sur le nombre d'objets créés, en l’occurrence les includes dans ce cas là, que ça pose soucis.

Chaque include créé équivaut à une nouvelle entrée dans la vue TADIR (vue sur la table des programmes).