Une des exigences de l'ingénierie du logiciel est la production de
composants assemblables et utilisables dans plusieurs réalisations,
comme dans toute autre activité industrielle. La mise en 
uvre de
cette exigence dans un langage de programmation est permise, d'une part
par la notion de module, d'autre part par des règles d'écriture
et d'usage de ces modules.
Plusieurs langages, notamment Modula 2 et Ada, ont été conçus autour de
la notion de module. L'idée est qu'un programme est formé à partir de
plusieurs modules ; les entités définies dans chaque module sont
classées en deux catégories : publiques ou privées. Les
entités publiques d'un module sont déclarées dans son interface
et sont exportables vers les autres modules, lesquels déclarent
dans leurs interfaces les entités qu'ils importent. Les modules
exportant des entités offrent des services dont sont
clients les modules qui les importent. En outre, la distinction
public/privé permet une discipline de noms : les noms privés, n'étant
pas connus à l'extérieur de leur module, peuvent être réutilisés sans
risque par d'autres modules. Le langage disposant actuellement de la
meilleure notion de module semble être Ocaml. Java met en uvre la
modularité à travers des mécanismes d'accessibilité et d'abstraction
portant sur ses paquets et ses types.
Loin d'être simplement un nouveau langage, Java est au cur d'une
nouvelle technologie, qui se déploie à la fois de façon matérielle
(futures cartes à puce, systèmes embarqués) et de façon logicielle sous
forme d'API spécialisée (Application Programming Interface), par
exemple pour l'accès aux bases de données, la programmation réseau ou
pour le graphique.
L'utilisation des APIs fait que de nombreuses applications
traditionnellement difficiles à programmer deviennent très simples.
Cependant, leur utilisation demande une certaine compréhension de leur
organisation, ce qui est l'un des objectifs de cette partie. Cette
organisation résulte d'une part de traits du langage Java (les
packages, les interfaces, les règles d'accessibilité,
les hiérarchies de types) et d'autre part, de l'application systématique
de certaines méthodes de conception, qui identifient des situations
typiques et des façons de les aborder et de les résoudre. Le besoin de
recourir à de telles méthodes de conception n'est pas propre à
l'informatique. La notion de pattern a été
développée à la fin des années 1970 par un architecte, Christopher
Alexander, qui les définit ainsi :
<<A pattern is a careful description of a perennial solution to a recurring problem within a building context, describing one of the configurations which brings life to a building. A pattern language is a network of patterns that call upon one another. An individual house might, for example, call upon the patterns described under the names of half-hidden garden, light from two sides in every room, variation of ceiling height, bed alcove, etc. Patterns help us remember insights and knowledge about design and can be used in combination to create designs.>>
Cette notion s'est vue réappropriée par des informaticiens, une dizaine d'années plus tard, et constitue actuellement l'une des approches les plus intéressantes de l'architecture des systèmes logiciels. Tant ces traits du langage que les patterns sont utiles à la programmation d'applications, pour peu que l'on s'efforce de les programmer proprement en respectant certains critères : indépendance de l'interface et de l'implémentation, facilité de modification ou de réutilisation, etc. Les choix que l'on fait quand on écrit un programme peuvent souvent se lire comme le choix d'un pattern contre un autre. Cette partie présentera quelques uns de ces patterns : fabrication, itération, décoration, visitation (?), etc.