Python 11.8 : Evolutions et problématiques

Continuons l'évolution de notre projet pizza. Pour le moment, nous avons une simple liste de noms de pizzas, mais nous voulons aller plus loin en associant à chaque pizza un prix. La question est : comment structurer cette donnée enrichie de manière propre et évolutive ? Cette leçon explore plusieurs approches et leurs limites, jusqu'à introduire la nécessité de passer à un autre paradigme.

Plusieurs approches et leurs limites

Une première idée serait de créer une seconde liste prix en parallèle, contenant les prix dans le même ordre que la liste pizzas. Mais cette approche pose un problème évident : les deux listes ne sont pas réellement synchronisées et il faudrait jongler avec les index pour les afficher ensemble. Toute modification d'une liste sans l'autre crée une incohérence silencieuse.

Une approche un peu meilleure consiste à utiliser une liste de tuples, où chaque tuple regroupe le nom et le prix d'une pizza :

pizzas = [
    ("4 fromages", 12.99),
    ("Végétarienne", 10.99),
    ("Hawaïenne", 11.50)
]

Pour accéder au nom on utilise l'index 0 du tuple, pour le prix l'index 1. C'est cohérent et synchrone, mais cette approche n'est pas idéale non plus si on veut enrichir encore : ajouter une liste d'ingrédients, un temps de cuisson, une catégorie. Le code devient difficile à lire car on manipule des index sans nom, et chaque ajout de propriété oblige à adapter tout le code qui parcourt la structure.

Les limites des structures imbriquées :

Lecture par index numérique peu expressive
Ajout de propriété fastidieux et risqué
Code de manipulation rigide et non évolutif
Pas de comportement (méthodes) attaché aux données

C'est exactement à ce moment qu'intervient la programmation orientée objet, qui permet de regrouper proprement les données et les comportements dans des classes. Dans la suite du cours, nous verrons comment écrire la version 2 de notre pizza sous forme d'objet, ce qui rendra notre code beaucoup plus lisible et facile à faire évoluer.

En résumé

Ce cours expose l'évolution d'un projet Pizza en Python, passant de simples listes de noms à l'ajout de prix. Il met en lumière les problématiques de synchronisation et de maintenance du code lorsqu'on gère plusieurs données hétérogènes. Le tuteur présente les tuples comme solution intermédiaire, puis en démontre les limites, justifiant ainsi le passage à la programmation orientée objet pour structurer les données de manière pérenne et évolutive.

Points clés

L'ajout de prix aux pizzas révèle le problème de synchronisation des listes parallèles (décalage possible entre noms et prix)
Les tuples regroupent plusieurs données (nom + prix) sous le même index, éliminant la désynchronisation
Chaque ajout d'attribut supplémentaire (ingrédients, calories…) oblige à adapter manuellement le code des tuples imbriqués
La limitation des tuples montre la nécessité de structures plus flexibles et maintenables
La programmation orientée objet est présentée comme la réponse idéale pour gérer des objets complexes et évolutifs
Transition du modèle données plat (listes) vers un modèle orienté objet (classes et instances)

Questions fréquentes

Pourquoi ajouter juste un prix crée-t-il un problème avec les listes simples ?

Avec une liste de noms et une liste de prix séparées, la synchronisation devient critique : il faut que l'index 0 du nom corresponde exactement à l'index 0 du prix. Si ces listes se désynchronisent, les données deviennent incorrectes et difficiles à afficher ensemble.

Qu'est-ce qu'un tuple en Python et comment cela résout-il le problème initial ?

Un tuple est une structure groupant plusieurs éléments (comme le nom et le prix) sous un même index. Cela lie les données ensemble : au lieu d'avoir deux listes parallèles, on a une seule liste de tuples, garantissant que chaque pizza a toujours un nom et un prix associés.

Pourquoi les tuples ne sont-ils pas la solution définitive ?

Si on veut ajouter d'autres attributs (ingrédients, calories, allergènes), on doit modifier les tuples et adapter le code partout où on les utilise. Cela devient pénible et peu maintenable. La programmation orientée objet offre une structure bien plus flexible et évolutive.