Discussion :

[shaiHulud]

Bonjour à tous,

En écrivant mon code, je me retrouve très souvent avec des imports cycliques (le module A importe le module B qui importe le module A). Je me débrouille pour que ca marche, mais je sais que c'est une pratique qui devrait être découragée.

Existe-t'il des principes généraux de conception pour éviter que cela arrive, ou est-ce une chose à réaliser au cas par cas ?

Voici quelques unes des raisons qui m'amènent à utiliser les imports cycliques et ce que j'imagine pouvoir faire pour l'éviter:

- Detection de type: une méthode du module A utilise un if obj.__class__ = classe_derivee_dans_le_module_B. Je pourrais dériver la methode dans le module B, mais parfois ce if ne sert qu'a éviter une seule instruction et il est dommage d'avoir deux fonctions quasiment identiques (surtout que ce genre de if est surtout utilisé pour débugger)

- Utiliser des petites fonctions simples. Dans ce cas, je suis censé creer un module C pour y mettre ces fonctions, et importer seulement ce module depuis B. Mais il est parfois plus naturel de mettre ces fonctions dans le module B (car les taches qu'elles réalisent sont intuitivement associées aux objets de B).

Merci d'avance pour votre éclairage sur ce sujet.

[nardo47]

Bonjour à tous,

Salut,

tout d'abord, je pense que ton thread serait plus à sa place sur la partie Conception de developpez.com.
Mais bon, on peut voir ce qu'on va tirer de pythonesque du sujet.

Existe-t'il des principes généraux de conception pour éviter que cela arrive, ou est-ce une chose à réaliser au cas par cas ?

Généralement, le bon sens et la méthode "je regroupe dans un module des choses qui ont une unité" me suffisent.

- une méthode du module A utilise un if obj.__class__ = classe_derivee_dans_le_module_B.

o_O
Alors, déjà, je déplacerais la fonction du module A vers le module B.
Ensuite, s'il s'agit d'une méthode, il va falloir revoir ton approche de la POO car c'est totalement contradictoire avec l'esprit objet. Charge à la classe B de redéfinir la méthode pour gérer le cas particulier.
Enfin, parlons un peu Python : si tu dois absolument effectuer le test, je te conseille de te servir de la fonction isinstance pour déterminer si un objet est d'une classe particulière.

Je pourrais dériver la methode dans le module B mais parfois ce if ne sert qu'a éviter une seule instruction et il est dommage d'avoir deux fonctions quasiment identiques (surtout que ce genre de if est surtout utilisé pour débugger)

A priori, je mettrais la partie de code "variable" dans une autre méthode qui serait appelée par la première, et c'est cette autre méthode que je réimplémenterais dans la classe fille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Spam(object):
 
    def methode_achement_importante(self):
        print "je débute !"
        self.petite_methode_de_debug()
        print "je termine !"
 
    def petite_methode_de_debug(self):
        print "je suis dans Spam !"
 
class Eggs(Spam):
 
    def petite_methode_de_debug(self):
        print "je suis dans Eggs !"

- Utiliser des petites fonctions simples. Dans ce cas, je suis censé creer un module C pour y mettre ces fonctions, et importer seulement ce module depuis B. Mais il est parfois plus naturel de mettre ces fonctions dans le module B (car les taches qu'elles réalisent sont intuitivement associées aux objets de B).

Je suis désolé, je ne comprends rien à cette partie.
Y-a-t'il vraiment une dépendance cyclique dans ce cas ?
Le fait de rajouter un module ne te donne-t-il pas une dépendance cyclique à 3 parties (A dépend de B qui dépend de C qui dépend de A) ?
Est-ce de l'injection de dépendance (ou de l'inversion de contrôle, la différence entre les 2, si elle existe, est beaucoup trop subtile pour moi) ?

Ce que je craignais en début de message se révèle exact : le sujet ne concerne Python que "pour la forme" : les problèmes de dépendances cycliques sont communs à tous les langages (en tout cas, tout ceux que je connais).

Demande plutôt de l'aide sur le forum conception.

[Zavonen]

Il est possible de générer des graphes de dépendances. Voir par exemple:
http://www.tarind.com/depgraph.html