Nous pouvons penser à la programmation orientée objet en tant que modélisation du comportement d'un système. Notez que le système ne doit pas nécessairement exister dans le "monde réel", bien que des métaphores du monde réel puissent parfois être utiles (par exemple, "pipelines", "usines", etc.).
Si notre système souhaité est trop compliqué à modéliser en une fois, nous pouvons le décomposer en éléments plus petits et les modéliser (le "domaine du problème"), ce qui peut impliquer une décomposition plus poussée, et ainsi de suite jusqu'à ce que nous obtenions des comportements dont le comportement correspond (plus ou moins) celui d'un objet langage intégré tel qu'un nombre, une chaîne de caractères, une liste, etc.
Une fois que nous avons ces pièces simples, nous pouvons les combiner pour décrire le comportement de pièces plus grandes, que nous pouvons combiner en pièces encore plus grandes, et ainsi de suite jusqu'à ce que nous puissions décrire toutes les composantes du domaine nécessaires à l'ensemble. système.
C'est cette phase de "combinaison" dans laquelle nous pourrions écrire certaines classes. Nous écrivons des classes quand il n'y a pas d'objet existant qui se comporte comme nous le voulons. Par exemple, notre domaine peut contenir des "foos", des collections de foos appelées "bars" et des collections de barres appelées "bazs". Nous pouvons remarquer que les foos sont assez simples pour modéliser avec des chaînes, alors nous le faisons. Nous constatons que les barres exigent que leur contenu obéisse à une contrainte particulière qui ne correspond à rien de ce que Python fournit, auquel cas nous pourrions écrire une nouvelle classe pour appliquer cette contrainte. Peut-être que les bazs n'ont pas de telles particularités, alors nous pouvons simplement les représenter avec une liste.
Notez que nous pourrions écrire une nouvelle classe pour chacun de ces composants (foos, bars et bazs), mais nous n’avons pas besoin de le faire s’il existe déjà un comportement correct. En particulier, pour une classe soit utile , il doit «fournir quelque chose (données, les méthodes, les constantes, les sous - classes, etc.), même si nous avons beaucoup de couches de classes personnalisées , nous devons éventuellement utiliser une fonctionnalité intégrée; Par exemple, si nous écrivions une nouvelle classe pour les foos, elle ne contiendrait probablement qu'une chaîne, alors pourquoi ne pas oublier la classe foo et laisser la classe bar contenir ces chaînes à la place? Gardez à l'esprit que les classes sont aussi un objet intégré, elles sont simplement particulièrement flexibles.
Une fois que nous avons notre modèle de domaine, nous pouvons prendre certaines instances particulières de ces éléments et les organiser dans une "simulation" du système particulier que nous souhaitons modéliser (par exemple, "un système d'apprentissage automatique pour ...").
Une fois que nous avons cette simulation, nous pouvons la lancer et hop, nous avons un système de travail (simulation d’un) apprentissage automatique pour ... (ou tout ce que nous modélisons).
Dans votre cas particulier, vous essayez de modéliser le comportement d'un composant "extracteur de fonctionnalités". La question est la suivante: existe-t-il des objets intégrés se comportant comme un "extracteur de fonctionnalités", ou devrez-vous les séparer en éléments plus simples? Il semble que les extracteurs de caractéristiques se comportent beaucoup comme des objets fonction. Je pense donc que vous seriez prêt à les utiliser comme modèle.
Une chose à garder à l'esprit lorsque vous étudiez ces types de concepts est que différentes langues peuvent fournir différentes fonctionnalités et objets intégrés (et, bien sûr, certains n'utilisent même pas une terminologie telle que "objets"!). Par conséquent, des solutions qui ont du sens dans une langue pourraient être moins utiles dans une autre (cela peut même s'appliquer à différentes versions de la même langue!).
Historiquement, une grande partie de la littérature de la programmation orientée objet (en particulier des "modèles de conception") s'est concentrée sur Java, qui est assez différent de Python. Par exemple, les classes Java ne sont pas des objets, Java n’avait pas d’objets fonction jusqu’à très récemment, Java applique une vérification de type stricte (ce qui encourage les interfaces et les sous-classes) tandis que Python encourage le typage, les Java, n’a pas d’objets modules, les entiers Java / flotteurs / etc. les objets ne sont pas des objets, la méta-programmation / introspection en Java nécessite une "réflexion", etc.
Je n'essaie pas de parler de Java (un autre exemple, beaucoup de théorie de la programmation orientée objet tourne autour de Smalltalk, qui est encore très différent de Python), j'essaie simplement de souligner que nous devons réfléchir très soigneusement au contexte et contraintes dans lesquelles des solutions ont été développées, et si cela correspond à la situation dans laquelle nous nous trouvons.
Dans votre cas, un objet de fonction semble être un bon choix. Si vous vous demandez pourquoi certaines directives de "bonne pratique" ne mentionnent pas les objets fonction comme solution possible, c'est peut-être tout simplement parce que ces instructions ont été écrites pour les anciennes versions de Java!
