Bonjour à tous,

Cet article se veut le premier d’une série sur les bonnes pratiques de développement ABAP telles que définies par les gens de SAP eux-mêmes. Après avoir longuement recherché de telles bonnes pratiques, j’ai fini par les trouver, et je souhaite les partager ici, reformatées avec mes mots.

Avant-propos…
Certaines des bonnes pratiques qui seront mentionnées ici ne sont pas forcément particulières au langage ABAP, mais s’appliquent bien sûr à tous les langages de programmation, avec plus ou moins d’adaptation. Ce sera le cas pour le présent article, par exemple.

Séparation des préoccupations…
Nous commencerons cette série en traitant de la séparation des préoccupations, qui sonne, il faut le dire, beaucoup mieux en anglais : separation of concerns (SoC).


La séparation des préoccupations est un principe utilisé en développement pour diviser une application en unités individuelles, dont les fonctions présentent un minimum d’intrications. Pour ce faire, on utilisera la modularisation, l’encapsulation et l’ordonnancement des couches logicielles.
L’architecture classique des systèmes SAP est une architecture en trois tiers. Et bien que cela soit idéal pour mettre en place le principe de SoC, cela n’avait jamais été mis en place (dans les programmes standard, j’entends). Les programmes applicatifs étaient historiquement gérés en un seul bloc monolithique, sans gestion de couches. Ce type de programmation n’est plus pertinent dans le monde du développement actuel !

Règle de base…
La bonne pratique SAP suggère d’utiliser ce principe de SoC le plus rigoureusement possible. Il est particulièrement important de séparer la logique de la couche applicative de celle de la couche de présentation, de la couche persistante et celle de la logique de communication avec des systèmes externes (quatre couches donc).

Détaillons un peu…
Le principe SoC identifie les parties d’une application ayant trait à un objectif donné, et les encapsule dans des unités individuelles. Ces dernières communiquent uniquement entre elles via des interfaces. Grâce à cela, le logiciel est découpé en composants maintenables, et le résultat est une application :

  • plus stable
  • plus compréhensible
  • plus réutilisable
  • plus maintenable
  • et plus facilement testable.

Mauvais exemple…
L’exemple de code présenté plus bas correspond au modèle de programmation propagé par SAP lui-même depuis un bon nombre d’années. Cependant, ils modernisent leur modèle de développement et souhaitent à présent que tous les développeurs ABAP suivent leurs nouvelles bonnes pratiques.
L’exemple ci-dessous est donc typique de la façon dont les différentes préoccupations (concerns) sont mélangées les unes aux autres dans une seule unité de programme. Les déclarations et l’implémentation des fonctions sont mélangées ; l’accès aux données persistantes, le traitement des données, leur présentation et les déclarations associées apparaissent tous dans une seule unité.

 

Alors bien sûr, il ne faut pas forcément que toutes les préoccupations soient systématiquement séparées. Dans un programme aussi court que celui-ci, cela serait chronophage. Cependant, les applications réelles sont généralement de (très) longs programmes ABAP dans lesquels tous ces préoccupations sont gérées en même temps.
Le peu de modularisation utilisée se réduit à réutiliser des unités fonctionnelles, mais ne se penche jamais, ou rarement, sur les couches logicielles. En outre, c’est souvent de grands volumes de données qui sont traités et utilisés dans les différentes procédures, ce qui a pour conséquence que toutes les parties du programme sont dépendantes entre elles et ne peuvent être testées individuellement.

Bon exemple procédural…
Dans le code source qui suit, on reprend les mêmes fonctions que le précédent, en implémentant le principe de SoC en mode procédural.
Toutes les préoccupations sont regroupées dans des procédures séparées qui sont affectées aux couches. C’est un peu trop pour un programme aussi simple, mais c’est pour l’exemple.

 

Bon exemple orienté objet…
Le code précédent est mieux que le premier. Cependant, et ce sera l’objet d’un article de cette série sur les bonnes pratiques, SAP recommande de ne plus développer qu’en ABAP objet. C’est pourquoi je vous propose un dernier exemple, isofonctionnel.

 

À première vue, cela paraît un peu excessif pour une si petite fonctionnalité. Mais il faut bien garder en tête que plus l’application est grande et réaliste, plus petite est la proportion de surcharge générée par l’encapsulation des préoccupations dans des classes. si les options de réutilisabilité des objets ABAP sont utilisées correctement, il est même possible de réduire la quantité de code source.
Enfin, les étapes individuelles sont à présent enveloppées dans des classes, c’est-à-dire de vraies unités de programme (contrairement au second code source). Dans la pratique, cette séparation n’est pas opérée dans un seul programme mais dans des classes globales, ce qui permet une meilleure réutilisation.

Et nous arrivons au terme de la présentation du principe de SoC tel que l’on peut le concevoir en ABAP. J’espère avoir été suffisamment clair. La partie commentaire est ouverte, n’hésitez pas à vous exprimer sur le sujet.

Le prochain article de cette série traitera du principe KISS et sera plus court.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.