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.