Introduction
Après des années à remplir des formulaires et à attendre, tu as enfin obtenu ta licence bancaire. Cela signifie que tu es désormais officiellement autorisé à ouvrir ta propre banque, hourra !
Ta première priorité est de mettre les systèmes informatiques en marche. Après une journée de dur labeur, tu peux déjà ouvrir et fermer des comptes, ainsi que gérer les retraits et les dépôts.
Comme tu n'avais pas envie de te fatiguer à écrire des tests, tu invites quelques amis à venir tester le système. Mais au bout de cinq minutes à peine, l'un de tes amis affirme avoir perdu de l'argent ! Même si tu es convaincu que ton code ne contient aucun bug, tu commences à parcourir les logs pour enquêter.
Ah oui, comme tu le soupçonnais, c'est ton ami qui est en tort ! Il a partagé ses identifiants de test avec un autre ami, et ensemble ils ont conspiré pour faire des dépôts et des retraits sur le même compte en parallèle. Qui ferait une chose pareille ?
Alors que tu soutiens qu'il est physiquement impossible d'accéder à son compte en parallèle, ton ami te fait remarquer d'un air suffisant que les règles bancaires exigent que tu prennes cela en charge. Donc, pas de prise en charge bancaire en parallèle, pas de feu vert pour la mise en production. Avec un soupir, tu prends mentalement note de t'y pencher demain. Cela repoussera ta date de lancement d'au moins un jour de plus, mais bon...
Instructions
Ta tâche consiste à implémenter des comptes bancaires qui prennent en charge l'ouverture et la fermeture, les retraits et les dépôts d'argent.
Comme on peut accéder aux comptes bancaires de bien des manières (internet, téléphones mobiles, prélèvements automatiques), ton logiciel bancaire doit permettre d'accéder aux comptes en toute sécurité depuis plusieurs threads/processus (la terminologie dépend de ton langage de programmation) en parallèle.
Par exemple, il peut y avoir de nombreux dépôts et retraits en parallèle ; tu dois t'assurer qu'il n'y a pas de conditions de concurrence entre le moment où tu lis le solde du compte et celui où tu définis le nouveau solde.
Il doit être possible de fermer un compte ; les opérations sur un compte fermé doivent échouer.
Python ne prend pas en charge la « véritable » concurrence à cause du Global Interpreter Lock.
Bien que des travaux soient en cours pour prendre en charge le free-threading en Python, celui-ci reste expérimental.
Les solutions actuelles de la bibliothèque standard, comme multiprocessing et threading, sont difficiles à mettre en œuvre avec l'outillage actuel du parcours.
Par conséquent, l'exigence de concurrence a été écartée pour cet exercice.
Les opérations sur le compte sont séquentielles, sur un seul thread, et aucun test de concurrence ou de « condition de course » n'est exécuté.
Si tu veux expérimenter le free-threading ou des tests de concurrence, nous te demandons de le faire en local.
Pour t'aider à télécharger les exercices et à travailler dessus en local, nous te recommandons l'Exercism CLI.
Messages d'exception
Il est parfois nécessaire de lever une exception. Dans ce cas, tu dois toujours inclure un message d'erreur explicite pour indiquer l'origine de l'erreur. Cela rend le code plus lisible et facilite grandement le débogage. Lorsque tu sais que l'erreur provient d'un type précis, tu peux lever l'un des types d'erreur intégrés, mais tu dois quand même inclure un message explicite.
Cet exercice demande d'utiliser l'instruction raise pour « lever » une ValueError lorsqu'un compte est ouvert ou non, ou lorsque les montants de retrait ou de dépôt sont incorrects. Les tests ne passeront que si tu fais à la fois raise de l'exception et que tu y joins un message.
Pour lever une ValueError avec un message, écris le message comme argument du type exception :
# account is not open
raise ValueError('account not open')
# account is already open
raise ValueError('account already open')
# incorrect withdrawal/deposit amount
raise ValueError('amount must be greater than 0')
# withdrawal is too big
raise ValueError('amount must be less than balance')
