POO – programmation orientée objet on kodkod | Cours d'introduction

Classes et objets : du problème à une classe complète

Mon, 01 Jan 0001 00:00:00 +0000

Dans cette leçon

Cette leçon est construite comme une seule histoire, dans le même ordre que les diapositives. Nous partons d’un petit système bancaire écrit avec des dictionnaires et des fonctions, nous voyons où il casse, et à chaque chapitre nous ajoutons un outil qui résout un problème :

Les objets au travail : état, masquage de l'information, properties et une classe complète

Mon, 01 Jan 0001 00:00:00 +0000

Dans cette leçon

Cette leçon est construite comme une seule histoire, dans le même ordre que les diapositives. Chaque chapitre s’appuie sur le précédent :

L'héritage et super : des classes semblables sans code dupliqué

Mon, 01 Jan 0001 00:00:00 +0000

Dans cette leçon

Cette leçon est construite comme une seule histoire, dans le même ordre que les diapositives :

Chapitre 1 — pourquoi l’héritage : deux fois le même code, et comment hériter au lieu de copier
Chapitre 2 — la redéfinition et super() : hériter, mais pas exactement — ne changer qu’une partie du comportement

À la fin de la leçon — de la pratique, et un mini-projet qui relie les deux chapitres.

Le polymorphisme : une interface commune, des comportements différents

Mon, 01 Jan 0001 00:00:00 +0000

Qu’allons-nous apprendre ?

Ce qu’est le polymorphisme (Polymorphism).
Une interface commune (Common Interface) : la même méthode, un comportement différent pour chaque type.
Pourquoi il remplace le if type == ....
Le Duck Typing : la version souple de Python.

Pourquoi en avons-nous besoin ?

Supposons qu’un système de paiement doive débiter un client, et que le client puisse payer par carte bancaire, par PayPal ou par virement bancaire. Sans polymorphisme :

La responsabilité unique en POO et la composition face à l'héritage

Mon, 01 Jan 0001 00:00:00 +0000

Qu’allons-nous apprendre ?

Le principe de responsabilité unique (SRP) au niveau d’une classe.
La composition (Composition) : un objet fait d’autres objets.
La composition face à l’héritage : comment choisir.

Pourquoi en avons-nous besoin ?

Dans le thème du code propre, nous avons appris le SRP pour les fonctions : chaque fonction fait une seule chose. Exactement le même principe s’applique aux classes, et il y est encore plus important, car une grosse classe est un « tas » de données et de comportements. Quand chaque modification (du format du ticket, du moyen de paiement, du calcul de la TVA) touche la même classe, elle devient fragile et effrayante à modifier.

Pratique guidée : d'une exigence verbale à une structure de classes

Mon, 01 Jan 0001 00:00:00 +0000

Qu’allons-nous apprendre ?

C’est une leçon atelier. Nous allons prendre une exigence verbale, et suivre ensemble tout le processus :

Lire et marquer.
Décider des classes.
La responsabilité et les données de chaque classe.
Les relations entre les classes.
Un squelette de code.
L’implémentation.
Les tests, et la correction de la conception.

Pourquoi en avons-nous besoin ?

Dans le projet de POO que vous construirez plus tard, avant d’écrire le code, il faut une étape de conception (Design). Cette leçon est la répétition générale : exactement le même processus, sur un problème différent, avec le formateur aux commandes.