Programmation modulaire
En informatique, la programmation modulaire reprend l'idée de fabriquer un produit (le programme) à partir de composants (les modules).
Elle décompose une grosse application en modules, groupes de fonctions, de méthodes et de traitement, pour pouvoir les développer et les améliorer indépendamment, puis les réutiliser dans d'autres applications.
Le développement du code des modules peut être attribué à des (groupes de) personnes différentes, qui effectuent leurs tests unitaires indépendamment.
Cette méthode de regroupement permet de réaliser une encapsulation comparable par certains aspects à celle de la programmation objet, et permet l'organisation du code source en unités de travail logiques. Les modules définissent également des espaces de noms utiles lors de leur utilisation.
La programmation modulaire n'implique pas l'usage d'un style de ou d'un paradigme de programmation particulier ; les éléments qu'elle structure peuvent être de style objet, impératif ou fonctionnel.
L'opposée de la programmation modulaire est le raffinement.
Ce style de programmation facilite grandement l'amélioration progressive, la ré-utilisabilité et le partage du code, et est particulièrement utile pour la réalisation de bibliothèques.
De plus, suivant les langages de programmation, les modules peuvent être paramétrés et/ou polymorphes (foncteur) ce qui apporte une modularité dont la souplesse décuplée amène alors à parler de généricité.
La programmation générique est un sur-ensemble qui peut tirer avantageusement parti de la modularité apportée par la programmation modulaire.
Le module comme composant
Les composants sont souvent perçus en termes de boites noires / boites blanches.
Un composant est vu comme une boîte noire lorsqu'on ne s'intéresse qu'à son usage et son comportement, défini par exemple par des spécifications, une notice d'emploi, un bornier : c'est le point de vue de l'utilisateur.
Un composant est vu comme une boîte blanche lorsqu'on s'intéresse à son organisation et à son fonctionnement : c'est le point de vue du concepteur, du fabricant, du réparateur.
De même, un module possèdera généralement :
- une interface spécifiant les fonctions et procédures fournies à l'utilisateur ;
- un corps les réalisant, à l'aide de toute variable, fonction ou procédure locale souhaitable ; cette localité sera une garantie contre des corruptions externes.
Si le corps du module doit exister, seule la connaissance de l'interface est nécessaire à son emploi.
Ainsi,
- améliorer une application restera simple si on améliore le corps des modules critiques sans modifier leurs interfaces ;
- réutiliser un module connu sera facile.
