Discussion :

[Julien N]

Salut,

Je souhaite faire un package. N'ayant pas de notions d'architecture logiciel, j'ai jeté un oeil à ce guide et à différentes sources pour l'inspiration. Pour faire court j'ai en tête cette organisation:

Code :

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

1
2
3
4
5
6
7
core/
    __init__.py
    solver.py
    solvers/
        __init__.py
        solverbase.py
        solver1.py

L'idée ici est de pouvoir ajouter différents solvers lorsque le projet évoluera. solver.py suit le design pattern "strategy" qui permet de créer à la volée l'un ou l'autre solver tout en conservant une syntaxe commune. Peut-être fais-je fausse route, n'hésitez pas à pointer un problème.
Je galère avec les imports relatifs. Il y a quelque chose qui m'échappe.

solver.py

Code :

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

1
2
3
4
5
6
7
from solvers import *
 
class Solver(object):
    def __init__(self):
        self.SolverStrat = solver1.Solver1
 
obj = Solver()

__init__.py (dans le dossier solvers)

Code :

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

__all__ = ['solver1']

solverbase.py

Code :

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

1
2
3
class SolverBase(object):
    def __init__(self):
        print('Init ok')

solver1.py

Code :

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

1
2
3
4
5
6
from .solverbase import SolverBase
 
class Solver1(SolverBase):
 
    def __init__(self):
        SolverBase.__init__(self)

Je m'attends à voir s'afficher 'Init ok' car à l'instanciation de l'objet Solver j'instancie en fait Solver1 qui lui même hérite de SolverBase. Sauf qu'il ne se passe rien. Si je print obj j'ai droit à une info sur l'objet en lui-même:

Code :

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

>>> __main__.Solver object at 0x00000000074F0F0

J'en déduit que l'instanciation n'a pas eu lieu. Mais pourquoi?

[wiztricks]

Salut,

"strategy" qui permet de créer à la volée l'un ou l'autre solver tout en conservant une syntaxe commune. Peut-être fais-je fausse route, n'hésitez pas à pointer un problème.
Je galère avec les imports relatifs. Il y a quelque chose qui m'échappe.

Il manque des () dans l'appel à solver1.Solver1
solver.py

Code :

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

1
2
3
4
5
6
7
from solvers import *
 
class Solver(object):
    def __init__(self):
        self.SolverStrat = solver1.Solver1
 
obj = Solver()

pour le reste, c'est galère de distribuer une construction dans 4 modules "à priori".
C'est plus simple de commencer par tout placer dans un module (quite à utiliser des classes emboîtées pour garder l'impression du nom de module) puis une fois que c'est stable, c'est plus facile à "distribuer".

- W

[Julien N]

Il manque des () dans l'appel à solver1.Solver1

Oook. J'étais tellement en train de réfléchir à l'architecture et à comment gérer les imports que je suis passé à côté de ça... Effectivement si demande pas l'instanciation explicitement ça marche moins bien.

Code :

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

1
2
3
4
class Solver(object):
    def __init__(self):
        SolverStrat = solver1.Solver1
        self.solver = SolverStrat()

Pour le reste, c'est galère de distribuer une construction dans 4 modules "à priori"

Est-ce que cela veut dire que ce n'est pas recommandé, voir déconseillé, ou est-ce juste une complication excessive? Dans la version actuelle du programme je n'ai qu'un fichier solver.py avec les différentes classes dedans. Mais différents solvers seront amenés à être créé. Et le module fait déjà pas mal de lignes d'où mon envie de découper cela.

La structure du module est plus complexe que l'exemple que j'ai fourni bien entendu, mais sur le même moule:

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
core/
    __init__.py
    solvers/
        __init__.py
        solverbase.py
        solver1.py
        solver2.py
    observers/
        __init__.py
        observerbase.py
        observer1.py
        observer2.py
    solver.py
    observer.py
    logic.py

Toute autre architecture me conviendrait pourvu qu'elle puisse me permettre assez simplement d'ajouter des "briques" par la suite.

J

[wiztricks]

Est-ce que cela veut dire que ce n'est pas recommandé, voir déconseillé, ou est-ce juste une complication excessive? Dans la version actuelle du programme je n'ai qu'un fichier solver.py avec les différentes classes dedans. Mais différents solvers seront amenés à être créé. Et le module fait déjà pas mal de lignes d'où mon envie de découper cela.

C'est un constat par rapport à mon expérience personnelle.
Le fait est que la structure va s'imposer dans le code. Donc si on décide d'un découpage à priori et qu'on n'a pas la chance d'avoir choisi le bon, on risque de se fatiguer à traîner un boulet lorsqu'on va généraliser.
note: personnellement, j'évite de trop découper avant d'être clair sur le plan de tests.

- W

[Julien N]

Le fait est que la structure va s'imposer dans le code.

C'est bien là tout mon problème. Je n'arrive jamais à avoir les idées claires sur la structure. Par manque de culture, de connaissances et d'expérience sans aucun doute. Merci pour les conseils.