Quand utilisons-nous réellement la programmation orientée objet?
J'écris un programme en Python, qui manipule essentiellement les chaînes, et je me demandais si je devais le faire en utilisant les principes OOP ou non. Le client m'a dit qu'il ne se souciait pas du code , il veut juste que la chose soit faite .
Je sais que le code orienté objet n'est pas par définition plus propre, et inversement le code non OO n'est pas par définition merdique. La question que je pose pourrait être plus ou moins fondée sur l'opinion, mais il pourrait y avoir certaines règles que je ne connais pas.
Quelques informations supplémentaires sur ce qui doit être fait:
- analyser un
.csvclasser et traiter les données sur la base d'un fichier de configuration (les colonnes peuvent être différentes - comme le nombre de colonnes ou les données qu'elles contiennent) - utiliser les données traitées ci-dessus pour créer de nouvelles données formatées personnalisées (ou plusieurs fichiers basés sur certaines des valeurs ci-dessus)
- utilisez les dernières données formatées pour créer un fichier XML.
- diviser le fichier XML en plusieurs
XMLs en fonction de leur contenu - l'application doit être basée sur CLI
- il y a bien sûr d'autres choses comme: la journalisation de certains événements, l'analyse des arguments CLI, etc.
Maintenant, ce n'est pas du tout une application grosse/dure, et elle est également presque terminée, mais pendant tout le processus de développement, je me demandais si cela devait être fait en utilisant OOP ou non.
Donc, ma question serait: comment les gars, savez-vous/décidez quand utiliser la POO dans une application?
Python est un langage multi-paradigme qui signifie que vous pouvez choisir le paradigme le plus approprié pour la tâche. Certaines langues comme Java sont à paradigme unique OO ce qui signifie que vous aurez des maux de tête si vous essayez d'utiliser un autre paradigme. Les affiches disant "toujours utiliser OO" sont venant probablement d'un bagage dans une telle langue. Mais heureusement vous avez le choix!
Je note que votre programme est une application CLI qui lit certaines entrées (fichiers csv et config) et produit des sorties (fichiers xml), mais n'est pas interactive et n'a donc pas d'interface graphique ou d'API avec état. Un tel programme est naturellement exprimé en fonction de l'entrée à la sortie, qui se délègue à d'autres fonctions pour les sous-tâches.
OO, d'autre part, consiste à encapsuler un état mutable et est donc plus approprié pour les applications interactives, les interfaces graphiques et les API exposant l'état mutable. Ce n'est pas un hasard si OO a été développé en parallèle avec les premières GUI.
OO a un autre avantage en ce que le polymorphisme vous permet une architecture à couplage plus lâche, où différentes implémentations de la même interface peuvent être facilement substituées. Combiné à l'injection de dépendances, cela peut permettre le chargement basé sur la configuration des dépendances et d'autres éléments intéressants. Ceci est cependant surtout approprié pour les très grandes applications. Pour un programme de la taille de ce que vous décrivez, ce serait beaucoup trop de frais généraux sans aucun avantage apparent.
Outre les fonctions de lecture et d'écriture des fichiers, l'essentiel de votre logique peut être écrit en tant que fonctions sans effets secondaires qui nécessitent une entrée et retournent une autre sortie. C'est éminemment facile à tester, beaucoup plus simple que de tester OO unités où vous devez vous moquer des dépendances et ainsi de suite.
Conclusion: je suggère un tas de fonctions divisées en modules pour l'organisation, mais pas d'objets.
Considérons un bouton sur une interface graphique. Il a un état (sa taille, sa couleur, sa position, son étiquette, etc.). Des choses peuvent lui arriver (il est cliqué, a besoin d'être redessiné, etc.). Dans de telles situations, la modélisation en tant qu'objet est logique. En tant qu'objet, il peut contenir son état, un ensemble d'actions qui peuvent être effectuées sur lui (méthodes) et il peut notifier aux autres parties de l'application que des choses lui sont arrivées en déclenchant des événements.
La POO est un superbe outil pour gérer les interfaces graphiques et d'autres situations où certaines parties du système ont un état volatil.
D'autres situations, comme celle que vous décrivez, où les données sont lues à partir d'une source, traitées et écrites vers une destination sont bien gérées par une approche différente: la programmation déclarative (ou fonction). Le code déclaratif pour le traitement des données a tendance à être à la fois plus facile à lire et plus court que les solutions OOP.
Tout comme un marteau et une scie sont deux outils puissants lorsqu'ils sont utilisés correctement, les techniques de programmation orientée objet et déclarative le sont aussi. Vous pourriez probablement enfoncer un clou dans un morceau de bois avec le manche d'une scie. De même, vous pouvez casser un morceau de bois en deux avec un marteau. De même, vous pouvez créer une interface graphique avec uniquement des fonctions et traiter les données avec des objets. Cependant, lorsque les outils sont utilisés correctement, les résultats sont plus nets et plus simples.
La règle générale que j'utilise est que si j'ai beaucoup d'état ou si j'ai besoin d'interaction avec l'utilisateur, j'utilise des objets; sinon j'utilise des fonctions (d'ordre pur et supérieur, si possible).
La programmation orientée objet ajoute quatre nouveaux outils à votre arsenal:
Vous utiliseriez OOP dans votre application lorsqu'elle sera suffisamment grande et suffisamment complexe pour bénéficier de ces outils.
Cette question me semble un peu confuse. Si vous l'écrivez en Python, vous allez sûrement utiliser des objets . Lorsque vous ouvrez un fichier, il renvoie un objet. Lorsque vous donnez un résultat, il renvoie un objet itérateur. Chaque fonction que vous créez est un objet. Questionner la valeur de OO in Python semblent pour le moins bizarres).
Sur la base des commentaires ici, oui, Python prend en charge les paradigmes fonctionnels mais il est principalement basé sur les objets. Le langage lui-même et les bibliothèques intégrées sont orientés autour des objets. Oui, il prend en charge lambda (tout comme Java et tout autre nombre de langages généralement décrits comme OO) mais c'est intentionnellement simpliste par rapport à un vrai langage fonctionnel.
Peut-être que ces distinctions autour de OO design et design fonctionnel deviennent obsolètes. Si je crée, prenez une fonction polymorphe sur un OO objet conçu * et passez un pointeur vers celui-ci) fonction sur un objet en tant que paramètre d'une fonction de style fonctionnel *, est-ce OO ou est-ce fonctionnel? Je pense que c'est les deux et aussi une approche vraiment efficace pour résoudre les problèmes.
Je pense que la vraie question est "quand devriez-vous commencer à concevoir vos propres classes plutôt que de simplement créer un module avec des fonctions? Je pense que la bonne réponse est: quand cela aide à simplifier la solution. Je donnerais la même réponse de base pour tout langage orienté objet.
* la redondance est intentionnelle: je ne veux pas être accusé ici de supposer que les objets sont OO ou que les fonctions sont fonctionnelles.
L'une des choses les plus importantes concernant la programmation orientée objet est qu'au lieu de raisonner sur le déroulement du programme, vous commencez à raisonner sur l'état.
Souvent, je vois l'objet, je vois les méthodes, mais ce que je vois aussi, c'est que la pensée motrice derrière le code est le flux plutôt que l'état.
Et une fois que vous raisonnez sur l'état, il est facile de construire un bon code OOP parce que dès que votre code devient trop complexe, vous remarquez que vous ne pouvez plus raisonner sur votre état et savez que vous devez refactoriser.
Considérez votre exemple: vous souhaitez analyser un fichier csv. D'où cela vient-il: un fichier sur disque. Vous le chargez et le mettez en mémoire et l'analysez. Maintenant, votre client arrive: hé, je veux aussi analyser des fichiers à partir du Web. Vous êtes donc content parce que vous avez créé une interface agréable pour charger votre fichier et que vous n'avez qu'à faire le code qui le récupère sur le Web et le reste de votre programme reste exactement le même.
Et la bonne chose est: vous pouvez tester cela.
En termes simples:
- Vous pouvez utiliser OOP ou non-OOP dans tout type de projets que vous souhaitez.
- La POO n'est pas la panacée mais elle permet de gérer la complexité.
- Cela va au-delà de la modularité, il s'agit de compartimentation. Pensez aux différents compartiments dont dispose un navire pour conserver sa flottabilité si la coque est endommagée.
- La POO est un moyen de gérer les dépendances afin que les bogues puissent être plus faciles à détecter car il n'y a qu'un ensemble défini de façons dont les différents composants d'un programme peuvent communiquer entre eux.
- Dans un programme, il y a beaucoup de choses qui fonctionnent: variables, constantes, méthodes, fichiers, paramètres, fonctions, modules, etc. Ils peuvent interagir les uns avec les autres de manière parfois imprévisible. OOP est un ensemble de principes qui réduisent le nombre de façons dont les choses peuvent interagir entre elles. Vous n'êtes pas obligé d'utiliser OOP pour ce faire, mais il aide.
Cela dit, il y a d'autres facteurs à prendre en compte:
- Vos programmeurs sont-ils compétents en OOP/OOD?
- Vos programmeurs maîtrisent-ils une langue OOP?
- Pensez-vous que le logiciel deviendra complexe au fil du temps?
- Envisagez-vous de faire évoluer ou de réutiliser le code à l'avenir?
- Pensez-vous que votre "design" peut devenir un atout? Par exemple, pourrez-vous en tirer parti pour vous développer ou servir de base à de futurs projets?
Ne vous méprenez pas: vous pouvez réaliser tout cela sans utiliser OOP mais avec OOP ce sera plus facile).
Mais...
Si votre équipe n'est pas compétente en OOP/OOD et n'a aucune expertise dans ce domaine, optez pour les ressources dont vous disposez.