Tout est des objets

1.1 Objets et classes

Aujourd'hui, tu vas découvrir comment est structuré un programme typique en Python. Et la grande nouvelle : chaque programme en Python est constitué de classes et d'objets. Python est un langage orienté objet, et tout est des objets : les nombres, les chaînes, les fonctions, et même les classes sont des objets.

Alors, c'est quoi les classes ?

Je vais commencer par une analogie. Imagine que tu veux construire un petit navire. D'abord, il faut faire le dessin, puis le donner à l'usine où, selon ce dessin, le navire sera construit. Ou une dizaine. En fait, autant de navires que souhaité. Selon un seul dessin, des dizaines de navires identiques sont construits, c'est ce qui est important.

En programmation Python, c'est pareil.

Les dessins

Un programmeur est comme un designer. Mais au lieu de dessins, le programmeur Python écrit des classes. Ensuite, sur la base des dessins, les pièces sont créées, et sur la base des classes, des objets sont créés.

D'abord, on écrit des classes (on fait des dessins), puis, pendant l'exécution du programme, Python crée des objets basés sur ces classes. Exactement comme les navires sont construits sur la base de dessins.

Il n'y a qu'un dessin, mais il peut y avoir beaucoup de navires. Les navires sont différents, avec des noms différents, transportant différentes cargaisons. Mais ils se ressemblent beaucoup : ce sont tous des navires avec une construction identique et peuvent accomplir des tâches similaires.

Encore une analogie...

La fourmilière

Une fourmilière est un bon exemple d'interaction d'objets. Dans la fourmilière la plus simple, il y a trois classes de fourmis : la reine, les soldats et les ouvrières.

Le nombre de fourmis de chaque classe est différent. Une reine par fourmilière, des dizaines de soldats, et des centaines de fourmis ouvrières. Trois classes et des centaines d'objets. Les fourmis interagissent entre elles, avec d'autres fourmis de même classe et d'autres classes selon des règles strictes.

C'est un exemple parfait. Dans un programme typique, c'est exactement pareil. Il y a un objet principal qui crée les objets de toutes les autres classes. Les objets commencent à interagir entre eux et avec le "monde extérieur" du programme. À l'intérieur de ces objets, leur comportement est programmé strictement.

Ces deux explications sont deux faces d'une même médaille. La vérité est entre les deux. Le premier exemple (à propos du dessin et des navires) montre le lien entre une classe et les objets de cette classe. L'analogie est très forte. Le second exemple (à propos de la fourmilière) montre le lien entre les objets qui existent pendant l'exécution du programme, et les classes écrites.

Tout d'abord, tu dois écrire des classes pour tous les objets existants dans le programme et ensuite décrire leur interaction. Ça a l'air compliqué, mais c'est plus simple qu'il n'y paraît.

En Python, toutes les entités pendant l'exécution du programme sont des objets, et l'écriture du programme se résume à décrire différentes façons d'interaction des objets. Les objets invoquent simplement des méthodes les uns sur les autres et transmettent les données nécessaires.

Documentation

Comment savoir quelles données transmettre dans les méthodes ? Tout cela a déjà été conçu pour toi.

En général, chaque classe a une description indiquant à quoi elle est destinée. En général, chaque méthode publique a une description : ce qu'elle fait et quelles données lui transmettre.

Pour utiliser une classe, il faut connaître en gros ce qu'elle fait. Et il faut savoir exactement ce que fait chaque méthode. Et ce n'est pas nécessaire de savoir comment elle le fait. Une sorte de baguette magique.

Regardons le code — copier un fichier :

src = open('source.txt', 'r')
dst = open('destination.txt', 'w')

for line in src:
    dst.write(line)

src.close()
dst.close()

Si tu lis ce code ligne par ligne, tu peux deviner ce qu'il fait en général. Bien qu'il faille un peu d'expérience et de pratique. Donc, après un certain temps, ce code te paraîtra familier et compréhensible.

1.2. Conception du programme

Concevoir un programme est tout un art. C'est à la fois simple et compliqué. Simple, parce qu'il n'y a pas de lois strictes : tout ce qui n'est pas interdit est autorisé. Compliqué aussi pour cette raison : il y a tant de façons de faire quelque chose, et il n'est pas facile de trouver la meilleure.

Concevoir un programme, c'est comme écrire un livre. D'une part, tu écris simplement des lettres, des mots, des phrases. Mais d'autre part, l'intrigue, les caractères des personnages, les contradictions internes, les conflits, le style de narration, l'intrigue, etc., sont importants.

L'important est de comprendre pour qui tu écris le code. Rappelle-toi que ton code est destiné à d'autres programmeurs.

Le développement de tout produit consiste à apporter des modifications : ajouter ici, supprimer là, refaire là-bas. Et ainsi, par petites itérations, naissent de grands, énormes et gigantesques projets.

La principale exigence pour le code — c'est qu'il doit être compréhensible par d'autres programmeurs. Un code incorrect, mais compréhensible peut être corrigé. Un code correct mais incompréhensible ne peut pas être amélioré. Il ne reste plus qu'à le jeter.

Alors, comment écrire du bon code compréhensible ?

Pour cela, tu dois faire trois choses :

• Écrire un bon code compréhensible à l'intérieur des méthodes — le plus simple.
• Décider quelles entités doivent être dans le programme.
• Bien diviser le programme en parties logiques.

Que signifient ces concepts ?

Écrire du bon code à l'intérieur des méthodes

Si tu as au moins un niveau de base en anglais, tu as peut-être remarqué à quel point le code est parfois facile à lire : comme des phrases en anglais :

• class Cat(Pet) – la classe Cat étend la classe Pet.
• while stream: – tant que le flux n'est pas vide ...
• a if a < b else b – si a est inférieur à b, renvoie a, sinon renvoie b.

C'est fait exprès. Python est l'un des rares langages où il est facile d'écrire du code auto-documenté : du code compréhensible sans commentaires. Dans un bon code en Python, de nombreuses méthodes se lisent simplement comme des phrases en anglais.

Ta tâche lorsque tu écris du code est aussi de le rendre aussi simple et concis que possible. Pense simplement à quel point le code sera facile à lire, et tu commenceras à aller dans la bonne direction.

En Python, il est habituel d'écrire du code facilement lisible. Idéalement, chaque méthode doit tenir entièrement sur l'écran (la longueur d'une méthode est de 20-30 lignes). C'est la norme pour toute la communauté Python. Si le code peut être amélioré, il doit être amélioré.

Le meilleur moyen d'apprendre à écrire du bon code est une pratique constante. Écris beaucoup de code, étudie le code des autres, demande à des collègues plus expérimentés de faire une revue de ton code. Et souviens-toi qu'au moment où tu te dis "ça ira", ton développement s'arrête.

Décider quelles entités doivent être dans le programme

Tu dois écrire du code qui est clair pour les autres programmeurs. Si 9 programmeurs sur 10 lors de la conception d'un programme vont créer les classes A, B et C, alors toi aussi tu dois créer les classes A, B et C dans ton programme. Tu dois écrire du code compréhensible par les autres.

Un excellent code, fonctionnel, rapide, non conventionnel est un mauvais code.

Tu dois étudier les projets des autres : c'est le meilleur, le plus rapide et le plus facile moyen d'acquérir toute la sagesse accumulée au fil des décennies dans l'industrie IT.

Et d'ailleurs, tu as déjà sous la main un excellent projet, populaire, bien documenté — Python SDK. Commence avec ça.

Analyse les classes et les structures de classes. Pense à pourquoi certaines méthodes sont statiques et d'autres non. Pourquoi les méthodes ont ces paramètres-là et pas d'autres. Pourquoi ces méthodes-là, pourquoi les classes s'appellent ainsi et se trouvent dans ces packages-là.

Quand tu commenceras à comprendre les réponses à toutes ces questions, tu pourras écrire du code compréhensible par les autres.

Cependant, je veux te mettre en garde contre l'analyse du code dans les méthodes du SDK Python. Le code de nombreuses méthodes a été réécrit pour maximiser la vitesse d'exécution — sa lisibilité est très discutable.

Bien diviser le programme en parties logiques

Habituellement, un programme est divisé en parties ou modules. Chaque partie est responsable d'un aspect spécifique du programme.

Par exemple, un ordinateur a une unité centrale, un écran, un clavier, et ce sont toutes des parties distinctes et faiblement couplées. De plus, leur interaction est standardisée : USB, HDMI, etc. Mais si tu renverses du café sur le clavier, tu peux simplement le laver sous le robinet, le sécher et l'utiliser à nouveau.

Par contre, un ordinateur portable est un exemple d'architecture monolithique : il y a des parties logiques, mais elles sont intégrées beaucoup plus fortement. Sur un Macbook Pro, pour nettoyer le clavier, il faut démonter la moitié de l'ordinateur portable. Et renverser du café sur un ordinateur portable est une raison de commander un nouveau. Sauf le café.

1.3 Créer ses propres classes

Lorsque tu commences à programmer, il est important de commencer petit — apprendre à créer tes propres classes.

Tu les as bien sûr déjà créées, mais tu dois apprendre à comprendre quelles classes doivent être dans le programme, comment elles doivent s'appeler, quels doivent être leurs méthodes. Et comment elles doivent interagir entre elles.

Liste des entités

Si tu ne sais pas par où commencer, commence par le début.

Au tout début de la conception du programme, tu peux simplement écrire sur une feuille une liste des entités (objets) qui doivent être dans le programme. Puis les programmer selon le principe : chaque entité — une classe distincte.

Exemple

Supposons que tu veux écrire un jeu d'échecs. Tu auras besoin de ces entités : un échiquier et 6 types de pièces. Les pièces se déplacent différemment, ont des valeurs différentes — il est logique que ce soient des classes distinctes. Et en général, au début, plus il y a de classes, mieux c'est.

Rencontrer un programmeur débutant qui aurait écrit dix classes au lieu de deux est rare. Mais écrire deux ou même une seule au lieu de dix, ça, les débutants aiment. Donc, plus de classes, chers programmeurs. Et ton code sera plus clair pour tout le monde, sauf peut-être pour toi 😛

Les échecs

Supposons que nous décidions d'écrire des classes pour les échecs : à quoi ressembleraient ces classes ?

Un échiquier — c'est juste un tableau de 8 par 8 ? Mieux vaut créer pour lui une classe distincte, qui à l'intérieur stocke un lien vers le tableau. Ensuite, dans la classe "échiquier", tu pourras ajouter de nombreuses méthodes utiles qui, par exemple, vérifient si une case est vide ou occupée.

Bref, au début, tu peux toujours te baser sur le principe suivant : Un programme a différentes Entités, et une Entité a un type. Ce type, c'est une classe.