Cet article est uneébauche concernant l’informatique.

Cet articlene cite pas suffisamment ses sources().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant lesréférences utiles à savérifiabilité et en les liant à la section « Notes et références ».
En pratique :Quelles sources sont attendues ?Comment ajouter mes sources ?En informatique, laprogrammation modulaire reprend l'idée de fabriquer un produit (le programme) à partir de composants (les modules).
Elle décompose uneapplication complexe enmodules, groupes de fonctions, de méthodes et de traitement. Chaque élément peut ainsi être développé, amélioré et optimisé indépendamment. Puis, il estréutilisable dans d'autres applications.
Le développement ducode des modules peut être attribué à des (groupes de) personnes différentes, qui effectuent leurstests unitaires indépendamment.
Cette méthode de regroupement permet de réaliser uneencapsulation comparable par certains aspects à celle de laprogrammation objet, et permet l'organisation du code source en unités de travail logiques. Les modules définissent également desespaces de noms utiles lors de leur utilisation.
La programmation modulaire n'implique pas l'usage d'un style de ou d'unparadigme deprogrammation particulier ; les éléments qu'elle structure peuvent être de styleobjet,impératif oufonctionnel.
L'opposée de la programmation modulaire est leraffinement.
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 debibliothèques.
De plus, suivant leslangages de programmation, les modules peuvent être paramétrés et/oupolymorphes (foncteur) ce qui apporte une modularité dont la souplesse décuplée amène alors à parler degénéricité.
Laprogrammation générique est un sur-ensemble qui peut tirer avantageusement parti de la modularité apportée par la programmation modulaire.
Les composants sont souvent perçus en termes de boites noires / boites blanches.
Un composant est vu comme uneboîte noire lorsqu'on ne s'intéresse qu'à son usage et son comportement. Il est 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 uneboî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 :
Si le corps du module doit exister, seule la connaissance de l'interface est nécessaire à son emploi.
Ainsi,