organiser le code 1

Salut,

J'aimerais savoir comment vous faites pour organiser votre code dans certaines situations :

Exemples :

J'ai une big class avec tout plein de méthodes du coup cela devient difficile à lire et à gérer...

Comment diviser la class, c'est-à-dire je voudrais dispatcher les différentes méthodes dans différents fichiers/modules...

Sachant que les méthodes utilisent des attributs de la class, que les méthodes peuvent dépendre les unes des autres...

Est-ce possible sachant que c'est juste pour que le code soit plus lisible ?

Pour l'instant je fais du bricolage (class dérivée de plusieurs class à qui je transmet une ref à la class mère, ça marche et l’autocomplétion fonctionne mais cela me semble être une mauvaise pratique). J'utilise aussi la "composition" au lieu de l’héritage mais cela peut parfois donner des expressions longues pour accéder à une méthode...

Citation:

---

Envoyé par Beginner.

J'ai une big class avec tout plein de méthodes du coup cela devient difficile à lire et à gérer...

Comment diviser la class, c'est-à-dire je voudrais dispatcher les différentes méthodes dans différents fichiers/modules...

---

Je pars du principe qu'une classe = une responsabilité. Pour les méthodes qu'elle contient, ce sont des petites choses qu'elles font et qui sont toujours propres à cette responsabilité.

Voyez, dans les-dites méthodes, si vous n'en avez pas qui font autre chose n'ayant rien à voir avec cette responsabilité.

Bon, c'est un peu abstrait ce que je dis, désolé.

Citation:

---

Envoyé par Beginner.

J'ai une big class avec tout plein de méthodes du coup cela devient difficile à lire et à gérer...

Comment diviser la class, c'est-à-dire je voudrais dispatcher les différentes méthodes dans différents fichiers/modules...

---

On prend un couteau et on découpe!

Plus sérieusement, avoir fait grossir une class et se poser ensuite la question d'en distribuer des bouts dans différents modules est assez perturbant: on met dans la même class méthodes et attributs qui ont une certaine cohérence vs l'objet correspondant et dans différents modules ce qui l'est moins.

Une démarche que j'utilise lorsque je "brouillonne" du code, c'est de faire grossir le script principal puis lorsqu'il est assez gros le découper en modules. Pour ce qui est du découpage d 'une class, c'est de la POO/conception (et il y a plein de tutos pour ça).

- W

Citation:

---

Envoyé par Arioch

Voyez, dans les-dites méthodes, si vous n'en avez pas qui font autre chose n'ayant rien à voir avec cette responsabilité.

---

On peut avoir une class avec beaucoup de méthodes ayant la même "responsabilité"...

Exemple : une class qui gère l'affichage de courbes peut contenir plusieurs méthodes :

- Des méthodes pour ajouter et supprimer des courbes...
- Des méthodes pour acquérir les mesures...
- Des méthodes pour mettre à jours les courbes...
- Des méthodes pour tracer les courbes...
- Des méthodes pour fixer les échelles,
- Des méthodes pour les autoscales (selon x, selon y, selon x et y)
- Des méthodes pour gérer l'impression...
- ...

A la fin cela peut devenir lourd sachant que certaines grosses méthodes peuvent faire appel à d'autres plus petites méthodes ...

Citation:

---

Envoyé par wiztricks

Pour ce qui est du découpage d 'une class, c'est de la POO/conception (et il y a plein de tutos pour ça).

---

Plein de tuto sur la POO, oui mais sur le découpage d'une class je ne sais pas...

J'ai trouvé ce fil ancien : Organiser ses classes

A voir...

Citation:

---

Envoyé par Beginner.

On peut avoir une class avec beaucoup de méthodes ayant la même "responsabilité"...

---

ouais mais c'est vous qui définissez les responsabilités.... et à partir de là, si vous vous retrouvez avec un gros tas, c'est le résultat de vos choix (de conception).

- W

Ben oui c'est le résultat de mes choix et j'ai réussi à découper ma class avec de l'héritage tout en réussissant à maintenir l'autocomplétion sous VSCode mais c'est je trouve du bricolage d'où mes questions...


Pour maintenir l'autocomplétion ce n'était pas évident, au début j'importais les modules de la class mère mais je me suis retrouvé avec des imports circulaires...

Ces imports c'était jute pour avoir le typage mais ça marche pas...

En TypeScript on peut ajouter des fichiers de définitions pour avoir tous les types et donc toutes les infos pour l'autocomplétion...

bonjour

Citation:

---

Envoyé par Beginner.

On peut avoir une class avec beaucoup de méthodes ayant la même "responsabilité"...
Exemple :
...

---

Tu n'a pas compris "la responsabilité" car ton exemple est justement mauvais. Dans ton exemple, c'est 3..4 classes voir + :
- modèle: stocker les données
- entrées: acquérir les mesures
- sorties: tracer les courbes (+ autre pour imprimer ?)
- controleur: faire les calculs (autoscales, echelles, ...)

Et cela, c'est pour un service unique !

ps: c'est du code tk, si je t'ai bien suivi ?

Citation:

---

Pour maintenir l'autocomplétion

---

Ici, on est dans un autre monde :mrgreen:

Citation:

---

Envoyé par papajoker

Tu n'a pas compris "la responsabilité" car ton exemple est justement mauvais. Dans ton exemple, c'est 3..4 classes voir + :

---

Oui mais chaque class ont des parties communes, elles doivent être liées d'une manière ou d'une autre...

Citation:

---

Envoyé par papajoker

Et cela, c'est pour un service unique !

---

Ben service unique ou même responsabilité cela se rejoint, non ? J'ai juste repris le mot "responsabilité"...

Citation:

---

Envoyé par papajoker

ps: c'est du code tk, si je t'ai bien suivi ?

---

Yes !

Citation:

---

Envoyé par Beginner.

Ben oui c'est le résultat de mes choix et j'ai réussi à découper ma class avec de l'héritage tout en réussissant à maintenir l'autocomplétion sous VSCode mais c'est je trouve du bricolage d'où mes questions...

---

La POO a inventé différents patterns de conception, d'architecture,... pour répondre à ces questions (et créer des relations entre classes qui ne se limitent pas à l'héritage - qui est souvent la plus mauvaise relation).
Donc pour faire autre chose que bricoler, il faut aller dans les rubriques adhoc pour voir ce qu'ils proposent comme tutos...

N'oubliez pas que c'est un problème de conception (avant l'écriture du code).

- W

Citation:

---

Envoyé par Beginner.

Ben service unique ou même responsabilité cela se rejoint, non ? J'ai juste repris le mot "responsabilité"...

---

Pas vraiment.
Imagine un simple export de données.
Il existe différentes méthodes pour exporter (xml, json, csv, etc.)
L'export est ton service mais tu as au moins 3 objets qui portent chacun la responsabilité d'écrire dans un format particulier (donc 3 responsabilités).

Ok mais ce que je veux dire c'est que tout doit être lié car pour reprendre ton exemple ces trois objets doivent tous les trois avoir accès aux données...

Ensuite pareil :
la class qui s'occupe d'afficher les courbes doit aussi avoir accès aux données...
la class qui s'occupe de faire les calculs pour les autoscales doit aussi avoir accès aux données et elle doit aussi avoir accès à l'affichage pour tracer les courbes, les axes...

Bonjour,

Citation:

---

Envoyé par Beginner

que les méthodes peuvent dépendre les unes des autres...

---

Je vois deux possibilités :

1. Passer des instances comme arguments, si une méthode d'une classe a besoin de faire appel à une méthode d'une autre classe, vous pouvez passer une instance de cette autre classe comme argument.
2. Utiliser l'injection de dépendances, ce principe permet de découpler les classes en rendant les dépendances externes plus explicites et en les injectant dans la classe depuis l'extérieur, souvent à travers le constructeur ou des setters.

Citation:

---

Envoyé par Beginner

Est-ce possible sachant que c'est juste pour que le code soit plus lisible ?

---

Si on veut rendre le code lisible, c'est pour le rendre plus maintenable, flexible aux changements avec le moins de complexité possible.

pensez à modéliser votre domaine en identifiant les entités, les valeurs objets, les agrégats, les services de domaine, et les repositories.
Cela peut aider à organiser votre code autour des concepts clés de votre domaine d'application.

En général ce genre de travail se fait avant de coder...

Citation:

---

Envoyé par Beginner

J'ai une big class avec tout plein de méthodes du coup cela devient difficile à lire et à gérer...

---

Dans certains cas, si votre classe effectue des opérations complexes qui ne se prêtent pas naturellement à une division en objets, envisagez de refactoriser ces opérations en services.
Un service est une classe qui effectue une opération ou une série d'opérations sans maintenir d'état interne, agissant plutôt sur les données qui lui sont fournies.

Par ex.

dans le contexte d'une application de gestion de commandes, les utilisateurs peuvent passer des commandes de produits.
Un service pourrait être utilisé pour calculer le total d'une commande en appliquant d'éventuelles réductions et en ajoutant les taxes.

Citation:

---

Envoyé par Beginner

J'utilise aussi la "composition" au lieu de l’héritage mais cela peut parfois donner des expressions longues pour accéder à une méthode

---

On ne choisit pas l'un ou l'autre et on fait avec, chacun a ses objectifs liés à ses besoins techniques.

L'héritage permet à une classe (appelée classe fille) de hériter des attributs et méthodes d'une autre classe (appelée classe parente), favorisant la réutilisation du code.
Il est généralement utilisé pour représenter des relations de type "est un(e)" entre les classes.

La composition est un principe de conception où une classe (le composite) contient des objets d'autres classes (les composants) pour réutiliser leur fonctionnalité.
Cela établit une relation de type "a un(e)" entre les classes.

La POO

On utilise la programmation orientée objet (POO) pour modéliser des concepts complexes sous forme d'objets interagissant entre eux, ce qui facilite la structuration, la réutilisation du code et la maintenance des applications en rendant le code plus modulaire, plus flexible et plus intuitif à comprendre.

• Si vous ne visualisez pas les objets de votre application, alors il est préférable de ne pas l'utiliser, car vous allez créer des classes qui n'ont aucun intérêt, à part vous entraîner à sa syntaxe.
• Si vous avez une bonne idée des objets de votre application, alors le découpage se fera plutôt de manière assez naturel.

Bonjour

Citation:

---

Envoyé par Beginner.

Ok mais ce que je veux dire c'est que tout doit être lié car pour reprendre ton exemple ces trois objets doivent tous les trois avoir accès aux données...

Ensuite pareil :
la class qui s'occupe d'afficher les courbes doit aussi avoir accès aux données...

---

Une classe "data" qui gère les données, qui offre des méthodes pour en entrer ou pour les récupérer. Et la classe "courbe" peut donc récupérer les données.

Citation:

---

Envoyé par Beginner.

la class qui s'occupe de faire les calculs pour les autoscales doit aussi avoir accès aux données et elle doit aussi avoir accès à l'affichage pour tracer les courbes, les axes...

---

Non. La classe qui s'occupe des calculs met alors à jour les données. Et ensuite la classe qui affiche la courbe récupère les données. Bref il faut une classe "maître" et toutes les autres s'adressent à elle. Et à mon avis les données sont toutes indiquées pour tenir ce rôle.

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 31

class data: def __init__(self, v1=0, v2=0): self.__v1=v1 self.__v2=v2   def __get(self): return self.__v1 def __set(self, v): self.__v1=v v1=property(__get, __set, None)   def __get(self): return self.__v2 def __set(self, v): self.__v2=v v2=property(__get, __set, None)   del __get del __set # data()   class calcul: def __init__(self, data): self.__data=data   def carre(self): self.__data.v1**=2 self.__data.v2**=2 # carre() # calcul()   d=data(5, 7) c=calcul(d) c.carre() print(d.v1, d.v2)

---

Sve@r,

On peut je pense partir sur un code plus simple, qu'en penses-tu ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Data: def __init__(self, **kwargs): self.__dict__['values'] = kwargs   def __getattr__(self, name): return self.values.get(name, 0)   class Calcul: def __init__(self, data_instance): self._data = data_instance   def carre(self): for key, value in self._data.values.items(): self._data.values[key] = value ** 2   d = Data(v1=5, v2=7) c = Calcul(d) c.carre() print(d.v1, d.v2)

---

EDIT : Sinon autre solution qui respecte plus l'encapsulation,

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

class Data: def __init__(self, **kwargs): self._values = kwargs   def __getattr__(self, name): return self._values.get(name, 0)   def __getitem__(self, key): return self._values.get(key, 0)   def __setitem__(self, key, value): self._values[key] = value   def keys(self): return self._values.keys()   class Calcul: def __init__(self, data_instance): self._data = data_instance   def carre(self): for key in self._data.keys(): value = self._data[key] self._data[key] = value ** 2   d = Data(v1=5, v2=7) c = Calcul(d) c.carre() print(d.v1, d.v2)

---

Salut,

@fred1599;12007412 & @Sve@r

Merci à vous deux, bon j'ai relu plusieurs fois vos messages, je dois encore réfléchir et faire des tests par rapport à certaines parties, à tête reposée...

Citation:

---

Envoyé par fred1599

1. Passer des instances comme arguments, si une méthode d'une classe a besoin de faire appel à une méthode d'une autre classe, vous pouvez passer une instance de cette autre classe comme argument.

---

Pour l'instant je m’arrête sur ce point car effectivement c'est une des solutions que j'ai utilisée et Sve@r en donne un exemple juste après...

Cette technique fonctionne aussi pour communiquer entre instances de class différentes (question de l'autre fil) mais cela devient fastidieux si on veut une communication bidirectionnelle... Et c'est encore bien pire si ce sont plusieurs instances de plus de deux class différentes qui doivent communiquer entre elles...

Citation:

---

Envoyé par Sve@r

Non. La classe qui s'occupe des calculs met alors à jour les données. Et ensuite la classe qui affiche la courbe récupère les données. Bref il faut une classe "maître" et toutes les autres s'adressent à elle. Et à mon avis les données sont toutes indiquées pour tenir ce rôle.

---

Merci pour l'exemple, pour l'instant pour la division d'une class j'ai utilisé l'héritage mais dit ci-dessus, cette technique fonctionne aussi pour communiquer entre instances de class différentes (question de l'autre fil).

Citation:

---

Envoyé par fred1599

On peut je pense partir sur un code plus simple, qu'en penses-tu ?

---

Effectivement il semble plus facile à comprendre...

Après il faut que je vois ce que cela peut donner avec plusieurs class qui doivent communiquer entre elles...

Citation:

---

Envoyé par fred1599

qu'en penses-tu ?

---

Oui bien sûr, mon exemple n'était qu'un exemple illustratif de ce qui est possible, un exemple parmis tant d'autres. J'ai probablement trop voulu protéger les attributs de data et donc effectivement ça devient un peu touffu dans cet objet. Ta dernière classe data a effectivement beaucoup de... classe 8-)

Citation:

---

Envoyé par Beginner.

Après il faut que je vois ce que cela peut donner avec plusieurs class qui doivent communiquer entre elles...

---

Pour que classeA et classeB puissent communiquer Il faut que classeA possède une méthode permettant à classeB de lui envoyer des infos... ou que classeB possède une méthode permettant à classeA de venir lui récupérer des infos.