Bug cognitif abc

Dans ma découverte de python je suis bloquer dans les structures de données et plus précisément le module abc : Je comprend toujours pas, après milles relectures, ce qu'est une classe ou une méthode abstraite.:calim2:

"""Une classe abstraite est une classe qui permet de définir un certain nombre de méthodes dites abstraites. Une méthode abstraite est une méthode qui n'est pas réellement utilisée dans un programme, mais qui sert de guide à l'ensemble des classes dérivées."""

Si quelqu'un peut m'expliquer a quoi sa rime et a quoi sa sert sa serai sympa car je bloque sur le sujet.:calim2:

Bonjour,

Il s'agit d'une facilité de construction et de gestion des classes.

Exemple: je dois construire 2 classes complexes qui ne se distinguent que d'une des méthodes (elles ont le même code à 90%).

Je peux construire les 2 séparément, mais je peux aussi construire une classe de base qui fait toute la partie commune, et les 2 classes qui m'intéressent par héritage avec seulement leur partie spécifique.

Dans le code qui suit, la classe 'base' (=abstraite) n'est pas faite pour être utilisée directement, mais seulement pour construire les classes actions1 et 2.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

################################################## class base(object):   def meth1(self): # traitement quelconque pass   def meth2(self): # methode abstraite: ne fait rien et doit être précisé # par héritage pass   def meth3(self): # traitement quelconque pass   ################################################## class action1(base):   def meth2(self): # traitement quelconque pass   ################################################## class action2(base):   def meth2(self): # traitement quelconque pass

---

Ce n'est qu'un exemple parmi d'autres.

Ok?

Tyrtamos

Salut,

Ce sont des concepts de programmation objet avancé.

La notion de classe "abstraite" est nécessaire aux langages "statiques".
Pour compiler une fonction qui appelle une autre fonction, il faut au moins connaître la signature (paramètres et types) de la fonction appelée.
Note: ce sont ces signatures qu'on met dans les headers d'un programme C/C++.
La réalisation de la fonction appelée peut être faite "après" ou même remplacée: tant qu'on ne change pas la signature pas besoin de recompiler le code des fonctions appelantes.

Cette mécanique est à la base de ce qu'on appelle bibliothèque ou DLL.
Elle permet de décomposer son application en morceau et de les assembler modulo non seulement le respect des signatures des fonctions mais aussi du protocole de l'interface.

Exemple: si on veut lire un fichier, il faudra l'ouvrir puis on pourra lire... on a donc deux fonctions à mettre en œuvre pour récupérer le contenu d'un fichier => c'est ce qui est relatif à "protocole" et "interface".

Avec la POO, les classes permettent d'avoir une granularité plus fine: on pourra regrouper certaines fonctions dans des classes pour les appliquer à tels types d'objets.
Compilation oblige: méthodes abstraites, classes abstraites,... pour séparer interfaces et réalisation.

Le programmeur Python s'en fout un peu: puisque c'est interprété, pas besoin de savoir "à l'avance". Il suffit que l'objet auquel on applique open/read/... ait les méthodes ad hoc lorsqu'on l'appelle.
C'est ce qui s'appelle aussi duck typing.

Et pourquoi ABC...
Ben parce que tous les projets Python un peu gros se retrouvent à devoir décomposer le "gros" truc en "composants".

Les composants ne sont définis que par les interfaces qu'ils proposent à ceux qui les utilisent. On dit d'un composant qu'il implémente ou réalise un type d'interface conforme à tel protocole.

A part çà on n'a pas trop envie de savoir comment ils sont réalisés, ils peuvent être pluggins ou échangeables, ils peuvent utiliser d'autres composants,... quoi d'autre?

Ceci dit, une architecture de composants n'étant pas une fonctionnalité spécifique à un langage de programmation difficile de faire consensus sur ce que çà peut signifier surtout lorsque "duck typing" ne rend pas la chose indispensable...

Mais vu le nombre d'architectures de composants qui poussent: Zope, Twisted, PyProtocols,... il y a un manque évident... ou le besoin de pourvoir d'appuyer sur un minimum qu'on n'a pas à ré-écrire.

abc est le compromis qui a été trouvé en attendant mieux.

On peut définir une classe "abstraite" parce que méthodes "abstraites".
Ce type de classe peut être vu comme "interface" ou "protocole" qu'un composant - ici une autre classe - réalise en sous-classant la classe abstraite ou en enregistrant qu'elle la réalise...
Le constructeur s'assure que les méthodes sont là.
Et l'appelant peut utilise isinstance pour savoir si une interface particulière est réalisée.

- W