Cette question est un peu agnostique au langage, mais pas complètement, car la programmation orientée objet (OOP) est différente, par exemple, en Java , qui n'a pas de fonctions de première classe, que ce n'est le cas en Python .
En d’autres termes, je me sens moins coupable de créer des classes inutiles dans un langage comme Java, mais j’ai l’impression qu’il existe peut-être une meilleure solution dans les langages moins cinglés tels que Python.
Mon programme doit effectuer plusieurs fois une opération relativement complexe. Cette opération nécessite beaucoup de "comptabilité", doit créer et supprimer des fichiers temporaires, etc.
C'est pourquoi il doit également faire appel à beaucoup d'autres "sous-opérations" - mettre tout en une seule méthode n'est pas très agréable, modulaire, lisible, etc.
Maintenant ce sont des approches qui me viennent à l'esprit:
1. Créez une classe qui ne possède qu'une méthode publique et conserve l'état interne nécessaire aux sous-opérations dans ses variables d'instance.
Cela ressemblerait à ceci:
class Thing:
def __init__(self, var1, var2):
self.var1 = var1
self.var2 = var2
self.var3 = []
def the_public_method(self, param1, param2):
self.var4 = param1
self.var5 = param2
self.var6 = param1 + param2 * self.var1
self.__suboperation1()
self.__suboperation2()
self.__suboperation3()
def __suboperation1(self):
# Do something with self.var1, self.var2, self.var6
# Do something with the result and self.var3
# self.var7 = something
# ...
self.__suboperation4()
self.__suboperation5()
# ...
def suboperation2(self):
# Uses self.var1 and self.var3
# ...
# etc.
Le problème que je vois avec cette approche est que l'état de cette classe n'a de sens que de manière interne et qu'il ne peut rien faire avec ses instances, à l'exception d'appeler leur seule méthode publique.
# Make a thing object
thing = Thing(1,2)
# Call the only method you can call
thing.the_public_method(3,4)
# You don't need thing anymore
2. Créez un ensemble de fonctions sans classe et transmettez entre elles les différentes variables nécessaires en interne (sous forme d'arguments).
Le problème que je vois avec ceci est que je dois passer beaucoup de variables entre les fonctions. En outre, les fonctions seraient étroitement liées les unes aux autres, mais elles ne seraient pas regroupées.
3. Comme 2. mais rendez les variables d'état globales au lieu de les transmettre.
Ce ne serait pas bon du tout, car je dois faire l'opération plus d'une fois, avec des entrées différentes.
Y a-t-il une quatrième meilleure approche? Si non, laquelle de ces approches serait la meilleure et pourquoi? Y a-t-il quelque chose qui me manque?