Aller au contenu

Conclusion

Si vous lisez cette page, c’est que vous avez fini le parcours sur la programmation orientée objet en Python.

Et avant de vous laisser, on va voir rapidement quelques notions un peu plus avancées (sans rentrer dans les détails), puis je vous donnerai un petit vric à vrac de projets que vous pouvez faire avec tout ce que vous savez maintenant.


Quelques notions avancées utiles

@property

En Python, on peut transformer une méthode en attribut calculé grâce à @property.

Par exemple :

class Player:
    def __init__(self, pv):
        self.pv = pv

    @property
    def alive(self):
        return self.pv > 0

Ici :

  • alive ressemble à un attribut
  • mais c’est en réalité une méthode
if player.alive:
    ...

Pourquoi c’est intéressant ?

  • ça évite de stocker des états redondants
  • ça réduit les bugs
  • ça rend le code plus lisible

C’est très utilisé dans du code Python propre.


Classes abstraites

Parfois, on veut dire :

“Cette classe est une base, elle ne doit jamais être utilisée telle quelle.”

C’est là que les classes abstraites entrent en jeu.

Exemple (simplifié) :

from abc import ABC, abstractmethod

class Spell(ABC):
    @abstractmethod
    def cast(self, caster, target):
        pass

Ici :

  • on ne peut pas instancier Spell
  • toute classe qui en hérite doit implémenter cast

C’est utile quand :

  • vous voulez imposer une structure
  • vous voulez éviter les oublis
  • votre projet devient un peu plus gros

Ce n’est pas obligatoire, mais c’est très pratique dans des projets plus ambitieux.


Différences avec la POO dans d’autres langages

Si vous venez (ou irez) vers :

  • Java
  • C++
  • C#
  • ou d’autres langages orientés objet

Il y a quelques différences importantes à connaître dans comment ces langages gèrent la POO :

  • Python est beaucoup plus permissif
  • pas besoin d’interfaces partout
  • pas besoin de tout typer

En contrepartie :

  • c’est à vous d’être discipliné
  • une mauvaise architecture peut facilement arriver

La POO en Python est donc :

  • plus souple
  • mais vous mets moins de garde-fou afin de vous obliger à faire un truc propre

Ce que vous avez fait dans ce parcours est totalement transférable vers d’autres langages objets.


Vric à vrac de projets

  • un roguelike plus complet
  • un jeu de cartes (deck, cartes, effets)
  • un simulateur de ferme / usine / ville
  • un jeu de gestion (argent, bâtiments, événements)
  • un jeu de combat au tour par tour à la Pokemon
  • un interpréteur de commandes (ok c'est moins sexy que les autres j'avoue)

Que faire à partir d'ici ?

Déjà si ce site vous a plus ou vous a aidé, alors soutenez moi en en parlant autour de vous et en le recommandant à d'autres personnes potentiellement intéressées.

Une suite naturelle à ce que vous venez d'apprendre est de créer des jeux avec Pygame, un parcours sur ce sujet sera normalement bientôt créé.

Sur ce, bon code à vous !