$course$/QCM de NSI/Terminale/Modularité et paradigmes Modularité d'un programme par séparation en modules
cohérents, paradigmes de programmation (impératif,
fonctionnel, objet), notion d'abstraction, intérêt
de la décomposition pour la lisibilité et la
réutilisation du code.

]]> Modularité et paradigmes — Q01 : Modularité d'un programme Qu'appelle-t-on la modularité d'un
programme ?

]]> Deux notions clés sont à retenir : la
cohésion (un module accomplit une
tâche, et la fait bien) et le
couplage faible (les modules
dépendent peu les uns des autres). On
cherche à maximiser la première et à
minimiser le second.

]]> 1.0 0.0 0 true true abc Sa qualité esthétique

]]> La modularité est une propriété
structurelle objective, et non un
jugement subjectif sur l'apparence
du code.

]]> Sa taille mesurée en nombre de lignes

]]> La taille en lignes ne reflète pas
la modularité d'un programme. Un
programme court peut être très peu
modulaire, et inversement.

]]> Sa rapidité d'exécution

]]> La rapidité d'exécution est une
propriété distincte. Un programme
modulaire peut être rapide ou
lent ; les deux qualités sont
indépendantes.

]]> Sa décomposition en modules (fonctions, classes, fichiers) cohérents et faiblement couplés entre eux

]]> Un programme modulaire est plus
lisible, plus testable et plus
facile à maintenir. La modularité
est l'un des piliers du génie
logiciel.

]]> Modularité et paradigmes — Q02 : Paradigme impératif Qu'est-ce que le paradigme impératif
en programmation ?

]]> Caractéristiques de ce paradigme :
utilisation de variables modifiables,
de boucles et d'instructions
séquentielles. Cette approche est
historiquement liée à l'architecture
de von Neumann.

]]> 1.0 0.0 0 true true abc Une simple variante du paradigme fonctionnel

]]> Les paradigmes impératif et
fonctionnel sont au contraire
très différents : ils s'opposent
notamment sur la place accordée à
la mutation des variables.

]]> Un style de programmation interdit par la loi

]]> Cette interprétation littérale du
mot « impératif » est sans rapport
avec son sens informatique. Aucun
paradigme de programmation n'est
interdit par une loi.

]]> Un paradigme inventé en $2020$

]]> Le paradigme impératif est très
ancien : il est associé aux
débuts mêmes de la programmation
dans les années $1950$.

]]> Un style de programmation où l'on donne des instructions à exécuter dans l'ordre, en modifiant l'état du programme par l'intermédiaire de variables

]]> C'est le style de programmation le
plus répandu, présent en C, en
Pascal, en Java, et partiellement
en Python. Il consiste à décrire
« comment faire » étape par
étape, à la manière d'une
recette.

]]> Modularité et paradigmes — Q03 : Paradigme fonctionnel Qu'est-ce que le paradigme
fonctionnel en programmation ?

]]> Avantages : un code plus prévisible
(sans effets de bord cachés), un
parallélisme facilité, et une plus
grande facilité de test. En
contrepartie, l'apprentissage peut
paraître exigeant pour quelqu'un
habitué au style impératif.

]]> 1.0 0.0 0 true true abc Un paradigme dédié à la gestion des erreurs

]]> La gestion des erreurs n'est pas
le sujet propre du paradigme
fonctionnel. Celui-ci concerne
plutôt la manière de structurer
les calculs autour de fonctions
sans effet de bord.

]]> Un style fondé sur l'évaluation de fonctions sans effet de bord, l'immuabilité des données et la composition de fonctions

]]> Les langages purement
fonctionnels les plus connus sont
Haskell, Lisp et OCaml. Python
permet aussi d'adopter certains
aspects fonctionnels, par exemple
avec les expressions lambda,
ou les fonctions map et
filter.

]]> Tout simplement un programme qui fonctionne correctement

]]> Cette interprétation littérale du
mot « fonctionnel » est trompeuse.
En programmation, le paradigme
fonctionnel renvoie à un style
précis, fondé sur l'évaluation de
fonctions sans effet de bord.

]]> Le même paradigme que l'impératif

]]> Les deux paradigmes s'opposent
sur des points fondamentaux,
notamment la mutation des
variables et la présence
d'effets de bord.

]]> Modularité et paradigmes — Q04 : Paradigme objet Qu'est-ce que la programmation
orientée objet ?

]]> La programmation orientée objet a été
formalisée par Alan Kay dans le
langage Smalltalk en $1972$. Elle
est particulièrement adaptée pour
modéliser des entités du monde réel
(Voiture, Personne, Compte
bancaire). Pour des problèmes
simples, elle peut toutefois
alourdir inutilement le code.

]]> 1.0 0.0 0 true true abc Le fait de coder en utilisant des objets physiques

]]> Cette interprétation littérale est
sans rapport avec le sens
informatique. Les objets en
programmation orientée objet sont
des entités logicielles
abstraites, pas des objets
physiques.

]]> Un paradigme aujourd'hui obsolète

]]> Au contraire, la programmation
orientée objet reste très utilisée
dans le monde du logiciel, et
notamment dans les grands projets
industriels.

]]> Une bibliothèque graphique

]]> Le paradigme objet est une manière
d'organiser le code en général,
et non une bibliothèque
particulière dédiée à
l'affichage.

]]> Un style structurant le code autour d'objets (instances de classes) qui combinent données (les attributs) et comportements (les méthodes)

]]> Java, C++, Python et Ruby sont
des langages très utilisés en
programmation orientée objet. Au
programme officiel : la définition
d'une classe, ses attributs, ses
méthodes, et la création
d'instances.

]]> Modularité et paradigmes — Q05 : Abstraction Qu'appelle-t-on abstraction en
programmation ?

]]> Tous les langages offrent des
mécanismes d'abstraction : les
fonctions, les modules, les classes,
les types abstraits. Un bon design
logiciel exploite ces mécanismes au
maximum pour produire un code
lisible et maintenable.

]]> 1.0 0.0 0 true true abc Un paradigme de programmation particulier

]]> L'abstraction est plus large
qu'un paradigme : elle traverse
tous les paradigmes (impératif,
fonctionnel, objet) et fait
partie du vocabulaire général de
la programmation.

]]> Une notion appartenant aux mathématiques

]]> Le mot « abstraction » a un sens
précis en mathématiques, mais on
parle ici de son sens
informatique : cacher les détails
d'une implémentation derrière une
interface.

]]> Le fait de cacher les détails d'une implémentation derrière une interface simple, de sorte que l'utilisateur d'une fonction n'ait pas à savoir comment elle est codée

]]> Par exemple, on utilise
len(liste) sans avoir besoin de
connaître l'implémentation de
cette fonction. L'abstraction est
le fondement même de la
modularité.

]]> Une obligation imposée par la loi

]]> L'abstraction est un principe de
conception, sans rapport avec une
quelconque obligation légale.

]]> Modularité et paradigmes — Q06 : Pourquoi découper un programme ? Pourquoi découper un programme en
plusieurs fonctions ou modules ?

]]> Une maxime classique du génie
logiciel résume bien cette idée :
« une fonction, une responsabilité ».
Si une fonction effectue plusieurs
tâches distinctes, mieux vaut la
scinder en autant de fonctions que
de responsabilités identifiées.

]]> 1.0 0.0 0 true true abc Pour améliorer la lisibilité, la réutilisation, la testabilité et la maintenance du code

]]> Un programme découpé en petites
unités cohérentes est nettement
plus facile à comprendre, à
tester et à faire évoluer dans
le temps.

]]> Pour gagner quelques secondes lors de la compilation

]]> Le gain en compilation, s'il
existe, est marginal et ne
constitue pas l'objectif
principal du découpage en
modules.

]]> Pour rendre le code plus complexe

]]> C'est exactement l'inverse. Le
découpage vise à simplifier
le code en le structurant en
petites unités intelligibles.

]]> Aucune raison particulière ne le justifie

]]> Le découpage répond au contraire à
plusieurs objectifs concrets,
comme expliqué dans la bonne
réponse.

]]> Modularité et paradigmes — Q07 : Paradigmes du langage Python Quel paradigme dominant caractérise
le langage Python ?

]]> Python est un langage multi-paradigmes
par conception. De nombreux langages
modernes le sont également
(JavaScript, Scala, Kotlin). Cette
flexibilité permet de choisir le
meilleur outil pour chaque situation.

]]> 1.0 0.0 0 true true abc Python est un langage multi-paradigmes : il permet de combiner les styles impératif, objet et fonctionnel selon les besoins

]]> Python permet de mélanger
librement les différents styles
de programmation. C'est un
langage très flexible, qui laisse
au programmeur le soin de
choisir l'approche la plus
adaptée au problème traité.

]]> Uniquement le paradigme objet

]]> Python est certes très orienté
objet en interne (toute valeur
est un objet), mais il accepte
parfaitement d'autres styles de
programmation, à commencer par
le style impératif.

]]> Uniquement le paradigme impératif

]]> Python ne se limite pas au style
impératif : il offre des outils
fonctionnels (lambda, map,
compréhensions) et un système
objet complet.

]]> Uniquement le paradigme fonctionnel

]]> Python n'est pas un langage
purement fonctionnel. Il accepte
la mutation des variables et les
effets de bord, qui sont au
contraire évités en
programmation purement
fonctionnelle.

]]> Modularité et paradigmes — Q08 : Importer un module En Python, comment importe-t-on des
fonctions définies dans un module
outils.py situé à côté du fichier
principal ?

]]> La modularité en Python repose sur
les modules, qui sont de simples
fichiers d'extension .py, et sur
les paquets, qui sont des dossiers
contenant un fichier __init__.py.
Ce mécanisme est simple à mettre en
œuvre.

]]> 1.0 0.0 0 true true abc Avec une directive include outils.py

]]> La directive include existe en
C ou en C++, mais pas en
Python. Le mécanisme d'import
est différent.

]]> Avec import outils (puis outils.fonction()), ou avec from outils import fonction

]]> Ce sont les deux syntaxes
standard. La première préserve
l'espace de noms du module ; la
seconde permet d'utiliser
directement la fonction
importée, sans préfixe.

]]> Avec l'instruction use outils

]]> La syntaxe use n'existe pas en
Python. C'est le mot-clé
import qu'il faut utiliser.

]]> Aucune syntaxe ne permet ce type d'import

]]> Python propose au contraire un
mécanisme d'import très complet,
comme indiqué dans la bonne
réponse.

]]> Modularité et paradigmes — Q09 : Avantage de la réutilisation Quel est le principal avantage de la
réutilisation de code déjà écrit ?

]]> Une bonne pratique consiste à se
familiariser avec la bibliothèque
standard de son langage avant
d'écrire du code soi-même. Beaucoup
de problèmes ont déjà une solution
éprouvée disponible.

]]> 1.0 0.0 0 true true abc Le code s'exécute plus rapidement

]]> La rapidité d'exécution n'est
pas systématiquement améliorée
par la réutilisation. Une
bibliothèque générique peut
parfois être plus lente qu'une
implémentation spécialisée.

]]> On code plus rapidement, et avec moins de bugs, car le code réutilisé a déjà été testé

]]> Plutôt que de tout réinventer, on
s'appuie sur du code existant,
qu'il s'agisse de la
bibliothèque standard du langage
ou de bibliothèques externes
reconnues. Cela permet un effet
d'échelle : un même code testé
sert à de nombreux programmes.

]]> Aucun avantage particulier

]]> La réutilisation apporte au
contraire des bénéfices
importants, comme expliqué dans
la bonne réponse.

]]> Le code occupe moins d'espace

]]> La place occupée n'est pas le
critère principal. La
réutilisation peut même
augmenter la taille du programme
si la bibliothèque utilisée est
volumineuse.

]]> Modularité et paradigmes — Q10 : Décomposition typique Pour calculer la moyenne d'une liste
de notes lue dans un fichier au format
CSV, quelle décomposition est la plus
propre ?

]]> Le principe de séparation des
préoccupations consiste à isoler
les entrées-sorties, le calcul, et
la présentation des résultats. C'est
une architecture classique, simple
et robuste.

]]> 1.0 0.0 0 true true abc N'utiliser aucune fonction

]]> Écrire un programme entier sans
aucune fonction est une mauvaise
pratique. Le découpage en
fonctions reste essentiel à la
lisibilité.

]]> Tout placer dans une seule fonction

]]> Une fonction qui mélange lecture,
calcul et affichage est plus
difficile à tester et à
réutiliser. Mieux vaut séparer
ces responsabilités.

]]> Trois fonctions distinctes, par exemple lire_csv, calculer_moyenne et afficher_resultat

]]> Chaque fonction a alors une
responsabilité claire et unique.
Chacune peut être testée
indépendamment et réutilisée
ailleurs dans le programme ou
dans un autre projet.

]]> Une seule fonction qui ne fait qu'un appel à print

]]> Cette décomposition est trop
minimaliste. Aucune des
opérations principales (lecture,
calcul) n'est isolée dans sa
propre fonction.

]]> Modularité et paradigmes — Q11 : Instancier une classe En Python, comment crée-t-on un objet
(une instance) à partir de la
classe Voiture ?

]]> Pour créer une instance, on appelle
simplement la classe en lui passant
les paramètres voulus, par exemple
v = Voiture("Renault", 2020).
Python crée alors l'objet et
appelle automatiquement la méthode
spéciale __init__ pour
l'initialiser.

]]> 1.0 0.0 0 true true abc Avec v = Voiture.instance()

]]> La méthode instance() n'est
pas la syntaxe standard
d'instanciation en Python.

]]> Avec la syntaxe v = Voiture()

]]> On appelle la classe comme une
fonction. Cet appel déclenche
l'exécution de la méthode
__init__ et renvoie le nouvel
objet créé.

]]> Avec v = create(Voiture)

]]> Aucune fonction create n'est
présente dans la bibliothèque
standard de Python pour
instancier une classe.

]]> Avec la syntaxe v = new Voiture()

]]> La syntaxe new existe en Java
ou en JavaScript, mais elle
n'est pas utilisée en Python.

]]> Modularité et paradigmes — Q12 : Accéder à un attribut Soit l'instance
v = Voiture("Peugeot", 2020). Comment
accède-t-on à l'attribut marque de
cet objet ?

]]> La notation objet.attribut
permet de lire ou de modifier un
attribut. La notation
objet.methode(...) permet
d'appeler une méthode définie sur
l'objet.

]]> 1.0 0.0 0 true true abc Avec la notation v::marque

]]> Le double deux-points est
utilisé en C++ (résolution de
portée), mais pas en Python.

]]> Avec la notation v[marque]

]]> Les crochets servent à indexer
une liste ou un dictionnaire,
et non à accéder à l'attribut
d'un objet.

]]> Avec la notation v.marque

]]> La notation pointée permet
d'accéder aussi bien aux
attributs qu'aux méthodes d'un
objet. C'est la syntaxe
standard en Python.

]]> Avec la notation v->marque

]]> La flèche -> est utilisée en
C ou en C++, mais pas en
Python.

]]> Modularité et paradigmes — Q13 : Fonction pure Qu'est-ce qu'une fonction pure, au
sens du paradigme fonctionnel ?

]]> Un avantage important des
fonctions pures est qu'elles
autorisent la mémoïsation, qui
consiste à mettre en cache les
résultats déjà calculés. Ces
fonctions facilitent aussi le
raisonnement mathématique sur le
programme.

]]> 1.0 0.0 0 true true abc Une fonction qui ne prend aucun paramètre

]]> Le nombre de paramètres n'a
aucun rapport avec la pureté
d'une fonction. Une fonction
pure peut prendre zéro, un ou
plusieurs paramètres.

]]> Une fonction écrite dans un langage mathématique

]]> Cette description est trop
vague. Une fonction pure se
définit précisément par
l'absence d'effet de bord et
par sa déterministicité, et non
par son expression dans un
langage particulier.

]]> Une fonction qui ne contient aucun bug

]]> La pureté n'a aucun rapport
avec l'absence de bugs. Une
fonction pure peut très bien
être incorrecte ; inversement,
une fonction avec effets de
bord peut être correcte.

]]> Une fonction qui, pour les mêmes paramètres, renvoie toujours la même valeur, sans aucun effet de bord (pas de modification d'une variable globale, pas d'entrée-sortie)

]]> Ce type de fonction est
prévisible, facilement
testable, et permet une
parallélisation aisée. Un
exemple : def carre(x): return
x * x. À l'inverse, une
fonction comme
def lire_fichier(f) n'est
pas pure, car elle effectue
une opération
d'entrée-sortie.

]]> Modularité et paradigmes — Q14 : Une fonction, une responsabilité Que recommande le principe
« une fonction, une
responsabilité » ?

]]> Si une fonction traiter lit un
fichier, effectue des calculs et
écrit le résultat, mieux vaut la
scinder en trois fonctions
distinctes, chacune dédiée à une
seule responsabilité.

]]> 1.0 0.0 0 true true abc Un programme ne doit posséder qu'une seule fonction

]]> Cette interprétation est
incorrecte. Un programme
contient en général de
nombreuses fonctions, chacune
ayant sa responsabilité
propre.

]]> Chaque fichier doit contenir une seule fonction

]]> Un module peut tout à fait
contenir plusieurs fonctions
liées à un même thème. Ce
principe ne porte pas sur
l'organisation des fichiers.

]]> Chaque fonction doit prendre exactement un seul paramètre

]]> Le nombre de paramètres n'a
aucun rapport avec ce
principe, qui concerne la
tâche accomplie par la
fonction.

]]> Chaque fonction doit accomplir une seule tâche clairement définie

]]> Ce principe est l'un des piliers
de la modularité. Une fonction
à responsabilité unique est
plus fiable, plus lisible et
plus facile à tester. Si l'on
ne peut pas décrire une
fonction en une phrase courte,
il vaut mieux la découper.

]]> Modularité et paradigmes — Q15 : Interface d'un module Que désigne l'interface d'un
module ou d'une fonction ?

]]> Une bonne pratique consiste à
« programmer contre une interface,
pas contre une implémentation ».
Cela rend le code robuste face
aux changements internes des
modules dont il dépend.

]]> 1.0 0.0 0 true true abc Uniquement la documentation du module

]]> La documentation décrit
l'interface, mais l'interface
elle-même est un concept plus
large : elle inclut aussi la
signature effective des
fonctions et leur
comportement.

]]> L'ensemble des points d'accès publics (signature, paramètres attendus, valeurs renvoyées, exceptions levées) que les utilisateurs peuvent consulter sans connaître l'implémentation

]]> L'interface joue le rôle d'un
contrat public. Tant que ce
contrat est respecté, on peut
modifier l'implémentation sans
impacter les utilisateurs du
module.

]]> Le code source du module

]]> Le code source représente
l'implémentation du module,
c'est-à-dire la manière dont il
fonctionne en interne. C'est
précisément ce que l'interface
cherche à masquer.

]]> Sa couleur d'affichage dans l'éditeur

]]> La couleur d'affichage relève
des préférences de l'éditeur,
et non de la définition d'une
interface en programmation.

]]> Modularité et paradigmes — Q16 : Style fonctionnel Laquelle de ces écritures est la plus
proche du style fonctionnel ?

]]> Quelques outils fonctionnels en
Python : map, filter,
reduce, lambda, zip et
enumerate. Ils sont
idiomatiques mais doivent être
utilisés avec discernement, sans
sacrifier la lisibilité.

]]> 1.0 0.0 0 true true abc carres = list(map(lambda x: x * x, liste))]]> La fonction map applique une
fonction à chaque élément
d'une collection, et lambda
permet de définir une fonction
anonyme à la volée. C'est
l'écriture la plus
caractéristique du style
fonctionnel.

]]> carres = liste.map(square)]]> Cette syntaxe n'est pas
valide en Python : les listes
ne possèdent pas de méthode
map. La fonction map est
une fonction native qui
s'utilise différemment.

]]> carres = [] for x in liste: carres.append(x * x)]]> Cette écriture est typique du
style impératif, avec une
boucle et des modifications
successives d'une variable.

]]> carres = [x * x for x in liste]]]> Cette compréhension de liste
adopte un style proche du
fonctionnel, mais l'écriture
la plus emblématique du style
fonctionnel utilise plutôt les
fonctions map ou filter
combinées à des fonctions
anonymes.

]]> Modularité et paradigmes — Q17 : Bibliothèques standard Pourquoi est-il préférable de
privilégier les bibliothèques
standard plutôt que de tout coder
soi-même ?

]]> Quelques bibliothèques standard
utiles en Python : math,
random, csv, json, os,
datetime, collections,
itertools. À cela s'ajoute un
écosystème externe très riche,
avec des bibliothèques comme
NumPy, pandas ou requests.

]]> 1.0 0.0 0 true true abc Aucun avantage à utiliser des bibliothèques

]]> Les bibliothèques apportent au
contraire de nombreux
avantages, comme détaillé dans
la bonne réponse.

]]> Parce que les bibliothèques standard sont obligatoires à utiliser

]]> Aucune obligation n'est
imposée. C'est une question
de choix raisonné, et non de
contrainte.

]]> Pour ralentir volontairement le programme

]]> Aucune bibliothèque n'est
conçue pour ralentir un
programme. La performance
n'est pas le critère
principal pour préférer une
bibliothèque, mais la qualité
et la fiabilité.

]]> Le code des bibliothèques standard est de qualité, testé par de nombreux utilisateurs, documenté et maintenu

]]> La probabilité de produire un
meilleur code seul, en
quelques heures, qu'une
bibliothèque standard
maintenue depuis des années
est très faible. Sauf cas
particuliers (apprentissage,
contraintes spécifiques), la
réutilisation est plus sage.

]]> Modularité et paradigmes — Q18 : Le paramètre self Dans la définition d'une méthode
Python, à quoi sert le premier
paramètre, traditionnellement nommé
self ?

]]> Lors d'un appel comme
v.afficher(), Python transmet
automatiquement l'objet v
comme premier paramètre self.
La méthode peut alors lire ou
modifier les attributs de v
via la notation
self.attribut.

]]> 1.0 0.0 0 true true abc C'est un mot-clé réservé qu'il ne faut jamais modifier

]]> Le nom self est une simple
convention, et non un mot-clé
réservé du langage. On
pourrait techniquement
l'appeler autrement, mais ce
serait fortement déconseillé,
car cela briserait les
habitudes des autres
développeurs.

]]> Il représente la classe elle-même, pas l'instance

]]> Le paramètre self représente
précisément l'instance
(l'objet créé), et non la
classe. Pour désigner la
classe elle-même, on utilise
plutôt cls dans les
méthodes de classe.

]]> Il est rempli automatiquement avec la valeur $0$

]]> Le paramètre self reçoit
l'objet courant lors de
l'appel, et non une valeur
numérique fixe.

]]> Il désigne l'instance sur laquelle la méthode est appelée

]]> Le paramètre self permet à
la méthode d'accéder aux
attributs et aux autres
méthodes de l'objet courant,
par exemple self.marque. Il
fait le lien entre la méthode
appelée et l'objet sur lequel
elle s'exécute.

]]> Modularité et paradigmes — Q19 : Classe et instance Quelle est la différence entre une
classe et une instance ?

]]> Une classe peut avoir aucune,
une, ou de très nombreuses
instances. Chaque instance
possède son propre état (ses
propres valeurs d'attributs),
mais les méthodes restent
définies une seule fois, dans
la classe.

]]> 1.0 0.0 0 true true abc Aucune différence

]]> Les deux notions sont au
contraire bien distinctes,
comme expliqué dans la bonne
réponse.

]]> La notion d'instance est aujourd'hui obsolète

]]> La notion d'instance reste
centrale en programmation
orientée objet : c'est l'objet
concret manipulé au cours de
l'exécution.

]]> La classe est le « plan » général (la description abstraite). L'instance est un objet concret créé à partir de ce plan

]]> Une analogie utile : la
classe est comme un moule à
gâteaux, et les instances
sont les gâteaux eux-mêmes.
On écrit class Voiture:
pour définir une classe et
ma_voiture = Voiture() pour
en créer une instance.

]]> La classe s'exécute plus rapidement que l'instance

]]> La rapidité d'exécution n'est
pas la différence pertinente
entre classe et instance. Ce
sont deux notions distinctes,
pas deux variantes d'un même
concept.

]]> Modularité et paradigmes — Q20 : Choisir un paradigme Quel paradigme de programmation
faut-il privilégier ?

]]> La tendance moderne est aux
langages multi-paradigmes, qui
permettent de mélanger les
meilleurs aspects de chaque
approche selon le contexte.

]]> 1.0 0.0 0 true true abc Le paradigme objet, dans tous les cas

]]> Cette position est trop
dogmatique. Aucun paradigme
n'est universellement
supérieur aux autres ; le
choix dépend du problème à
résoudre.

]]> Le paradigme fonctionnel, dans tous les cas

]]> Cette position est elle
aussi trop dogmatique. Le
paradigme fonctionnel
excelle pour les
transformations de données,
mais il n'est pas toujours
le plus naturel pour tous
les problèmes.

]]> N'importe quel paradigme convient toujours

]]> Il existe souvent un choix
plus pertinent qu'un autre,
en fonction de la nature du
problème à résoudre.

]]> Le choix dépend du problème : le paradigme objet pour modéliser des entités complexes ; le paradigme fonctionnel pour des transformations de données ; le paradigme impératif pour des algorithmes simples et directs

]]> Aucun paradigme n'est
universellement meilleur. Un
bon programmeur sait choisir
l'outil adapté au contexte.
Beaucoup de programmes
modernes mélangent
d'ailleurs plusieurs
paradigmes au sein d'un même
projet.

]]> Modularité et paradigmes — Q21 : Couplage entre modules Qu'appelle-t-on le couplage entre
modules ?

]]> Une astuce utile : si l'on ne
peut pas modifier un module sans
en regarder cinq autres, le
couplage est trop fort. Il faut
alors refactoriser, par exemple
en introduisant des interfaces
claires et en isolant les
dépendances.

]]> 1.0 0.0 0 true true abc Le nombre de fonctions définies dans chaque module

]]> Le nombre de fonctions est
une mesure de taille, pas une
mesure de dépendance entre
modules.

]]> Une union solennelle entre deux modules

]]> Cette interprétation
littérale est sans rapport
avec le sens technique du mot
« couplage » en
programmation.

]]> Une opération mathématique sur les modules

]]> Le mot « couplage » est ici
utilisé dans un sens
informatique précis, sans
rapport avec une opération
mathématique.

]]> Le degré de dépendance entre modules. On vise un couplage faible, c'est-à-dire des modules peu liés, modifiables indépendamment les uns des autres

]]> Un couplage faible permet de
remplacer ou de modifier un
module sans avoir à toucher
aux autres. Un couplage fort,
au contraire, impose de
modifier plusieurs modules
simultanément à chaque
changement.

]]> Modularité et paradigmes — Q22 : Piège classique de la programmation orientée objet Quel est un piège classique de la
programmation orientée objet ?

]]> Une bonne maxime : choisir
l'outil adapté au problème. Une
classe pour seulement deux
fonctions s'apparente à un
empilement inutile. À partir
d'une méthode importante avec
un état persistant, la classe
devient en revanche pertinente.

]]> 1.0 0.0 0 true true abc Coder de manière trop simple

]]> Le piège évoqué ici est
précisément l'inverse :
c'est l'excès de complexité
qui pose problème, pas la
simplicité.

]]> La programmation orientée objet ne présente aucun piège

]]> Comme tout paradigme, la
programmation orientée objet
a ses pièges, dont l'excès
de modélisation est l'un des
plus classiques.

]]> Modéliser sous forme de classes des situations qui ne le justifient pas, ce qui complique inutilement le code

]]> Pour calculer une simple
somme de notes, il n'est pas
nécessaire de créer une
classe CalculateurDeMoyenne.
Une fonction suffit
largement. La programmation
orientée objet a un coût en
complexité qu'il faut savoir
peser.

]]> Utiliser des fonctions classiques

]]> Utiliser des fonctions n'est
pas un piège ; c'est au
contraire souvent la bonne
solution face à des
problèmes simples.

]]> Modularité et paradigmes — Q23 : Définir une classe Quel squelette permet de définir une
classe Point avec deux attributs x
et y initialisés à la création ?

]]> Le constructeur s'écrit
toujours sous la forme
def __init__(self, …): et
stocke les paramètres reçus
dans self. Pour instancier la
classe, on écrit par exemple
p = Point(3, 4) ; ensuite,
p.x vaut $3$ et p.y vaut
$4$.

]]> 1.0 0.0 0 true true abc def Point(x, y): self.x = x self.y = y]]> Cette définition utilise
def, qui définit une
fonction, et non une classe.
Il manque le mot-clé
class.

]]> class Point(x, y): return x, y]]> Les parenthèses qui suivent
le nom d'une classe ne
servent pas à déclarer ses
attributs. Une définition
de classe ne renvoie pas
non plus de valeur.

]]> class Point: x, y]]> Cette syntaxe n'est pas
valide en Python. De plus,
aucun attribut ne serait
initialisé.

]]> class Point: def __init__(self, x, y): self.x = x self.y = y]]> La méthode __init__ est
appelée automatiquement à la
création de l'objet. Elle
reçoit self, puis les
valeurs initiales, et les
stocke en tant qu'attributs
de l'instance.

]]> Modularité et paradigmes — Q24 : Paradigme déclaratif En quoi le paradigme déclaratif
se distingue-t-il du paradigme
impératif ?

]]> La tendance moderne est de
monter en abstraction, en
déclarant ce que l'on veut
plutôt qu'en décrivant
l'implémentation. Par exemple,
la bibliothèque React (style
déclaratif) s'oppose au style
impératif d'une bibliothèque
comme jQuery.

]]> 1.0 0.0 0 true true abc Aucune différence n'existe entre les deux paradigmes

]]> Les deux paradigmes
diffèrent au contraire de
manière fondamentale dans
la manière de formuler le
problème.

]]> Le paradigme déclaratif n'existe pas

]]> Le paradigme déclaratif
existe bel et bien et est
utilisé dans de très
nombreux langages
spécialisés.

]]> Le paradigme déclaratif dit ce que l'on veut, sans préciser comment l'obtenir (SQL, HTML, expressions régulières) ; le paradigme impératif, à l'inverse, décrit comment faire étape par étape

]]> Le paradigme fonctionnel et
le paradigme logique
(Prolog) sont deux variantes
déclaratives. Le langage
SQL est typiquement
déclaratif : on demande
« les noms des étudiants
ayant obtenu plus de $10$ »
sans préciser comment
effectuer la recherche.

]]> Le paradigme déclaratif est plus rapide à exécuter

]]> La rapidité n'est pas le
critère pertinent. La
distinction porte sur la
manière d'exprimer le
problème.

]]> Modularité et paradigmes — Q25 : Synthèse Parmi les affirmations suivantes
sur la modularité et les
paradigmes, laquelle est
fausse ?

]]> Les langages purement
fonctionnels les plus connus
sont Haskell et Idris. Les
langages multi-paradigmes
incluent Python, JavaScript,
Scala et OCaml.

]]> 1.0 0.0 0 true true abc Python est un langage purement fonctionnel

]]> Cette affirmation est fausse
(donc c'est la bonne
réponse). Python est un
langage multi-paradigmes.
Il prend en charge des
aspects fonctionnels
(lambda, map,
compréhensions), mais il
autorise aussi la mutation
des variables et les effets
de bord, ce qui n'est pas
possible dans un langage
purement fonctionnel.

]]> La modularité améliore la maintenabilité du code

]]> Cette affirmation est
correcte. La modularité est
précisément un facteur clé
de maintenabilité.

]]> Une fonction pure n'a pas d'effet de bord

]]> Cette affirmation est
correcte. L'absence d'effet
de bord est précisément ce
qui définit une fonction
pure.

]]> Le paradigme objet structure le code autour d'objets combinant données et comportements

]]> Cette affirmation est
correcte. C'est même la
définition du paradigme
objet.

]]> Modularité et paradigmes — Q26 : Encapsulation Que désigne le principe
d'encapsulation en programmation
orientée objet ?

]]> L'encapsulation favorise le
couplage faible : un objet expose
uniquement ce dont les autres ont
besoin (son interface publique) et
cache le reste. C'est la base du
principe « programmer contre une
interface, pas contre une
implémentation ».

]]> 1.0 0.0 0 true true abc Réutiliser les classes
d'un autre programme

]]> Erreur : la réutilisation est
un autre concept (lié à la
modularité). L'encapsulation
concerne le masquage des
détails internes derrière une
interface publique.

]]> Mettre tout le code d'une
application dans un seul fichier

]]> Erreur : c'est l'inverse de la
modularité. L'encapsulation va
précisément dans le sens
opposé : on isole les
responsabilités dans des objets
(ou modules) distincts.

]]> Compresser un fichier avant de
l'envoyer

]]> Erreur : la compression de
données est sans rapport avec
le concept d'encapsulation. Le
terme « encapsulation » a un
sens informatique précis,
différent.

]]> Regrouper dans un même objet les
données (attributs) et les
traitements (méthodes) qui
s'appliquent à ces données, en
masquant à l'extérieur les
détails d'implémentation

]]> Bonne réponse : c'est l'un des
piliers de la programmation
orientée objet. L'utilisateur
d'un objet manipule l'interface
publique (les méthodes) sans
dépendre du fonctionnement
interne (les attributs). On
peut alors modifier
l'implémentation sans casser
le code utilisateur, tant que
l'interface reste stable.

]]> Modularité et paradigmes — Q27 : Convention de visibilité en Python En Python, comment indique-t-on
conventionnellement qu'un attribut
ou une méthode est destiné à un
usage interne (et ne fait pas
partie de l'interface publique) ?

]]> Python privilégie la philosophie
« We are all consenting adults »
(« nous sommes tous des adultes
consentants ») : le langage ne
bloque rien, mais la convention
de l'unique soulignement signale
qu'on ne doit pas accéder à
l'attribut depuis l'extérieur.
C'est moins strict qu'en Java ou
en C++, mais plus souple.

]]> 1.0 0.0 0 true true abc En écrivant le nom en majuscules

]]> Erreur : la convention des
majuscules désigne plutôt les
constantes en Python
(PI, MAX_SIZE). Elle n'a
aucun rapport avec la
visibilité.

]]> En préfixant le nom par un dièse
(#nom)

]]> Erreur : le dièse n'a pas ce
rôle en Python. Il introduit
un commentaire de fin de
ligne, ce qui n'a aucun
rapport avec la visibilité
des attributs.

]]> En préfixant son nom par un
unique caractère de soulignement
(par exemple _etat_interne)

]]> Bonne réponse : c'est la
convention pythonique. Cet
unique préfixe ne change rien
au niveau du langage (l'accès
reste possible techniquement),
mais il indique clairement aux
autres développeurs que
l'attribut ne fait pas partie
de l'API publique. C'est une
forme d'encapsulation par
convention. Le double
soulignement (__nom)
déclenche en plus le
name mangling (renommage
interne).

]]> Avec le mot-clé private

]]> Erreur : le mot-clé private
existe en Java, en C++, en
C#, mais pas en Python. Le
langage ne permet pas de
rendre un attribut
strictement privé : tout
repose sur des conventions.

]]>