Quand utilisons-nous réellement la programmation orientée objet? [fermé]

J'écris un programme en Python, qui manipule essentiellement des chaînes, et je me demandais si je devais le faire en utilisant les principes de la programmation orientée objet ou non. Le client m'a dit qu'il ne se souciait pas du code, il voulait 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, de mauvaise qualité. La question que je pose est peut-être plus ou moins basée sur l'opinion, mais il y a peut-être certaines règles que je ne connais pas.

Quelques informations supplémentaires sur ce qui doit être fait:

• analyser un .csvfichier 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 une nouvelle donnée formatée personnalisée (ou plusieurs fichiers en fonction de 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 fichiers en XMLfonction de leur contenu
• l'application doit être basée sur CLI
• il y a bien sûr d'autres choses telles que: la journalisation de certains événements, l'analyse d'arguments CLI, etc.

Maintenant, ce n’est pas du tout une application volumineuse / dure, et c’est aussi presque fini, mais pendant tout le processus de développement, je me demandais si cela devait être fait en utilisant ou non la POO.

Ma question serait donc la suivante: comment savez-vous / décidez-vous quand utiliser la POO dans une application?

Python est un langage multi-paradigme, ce qui signifie que vous pouvez choisir le paradigme le plus approprié à la tâche. Certaines langues comme Java sont à paradigme unique OO, ce qui signifie que vous aurez mal à la tête si vous essayez d’utiliser un autre paradigme. Les affiches disant "toujours utiliser OO" viennent probablement d'un contexte dans une telle langue. Mais heureusement vous avez le choix!

Je remarque que votre programme est une application CLI qui lit certaines entrées (fichiers csv et config) et génère des sorties (fichiers xml), mais n’est pas interactif et n’a donc pas d’interface utilisateur graphique ou d’API. Un tel programme s’exprime naturellement comme une fonction d’entrée en sortie, qui délègue à d’autres fonctions des sous-tâches.

D'autre part, OO concerne l'encapsulation de l'état mutable et est donc plus approprié pour les applications interactives, les interfaces utilisateur 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 interfaces graphiques.

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épendance, cela peut permettre le chargement de dépendances et d'autres éléments intéressants en fonction de la configuration. Ceci est surtout approprié pour les très grandes applications. Pour un programme de la taille de ce que vous décrivez, il en coûterait beaucoup trop de frais généraux sans bénéfice apparent.

Outre les fonctions qui lisent et écrivent les fichiers, le gros de votre logique peut être écrit sous forme de fonctions sans effets secondaires qui prennent une entrée et retournent une autre sortie. C'est éminemment facile à tester, beaucoup plus simple que de tester des unités OO où vous devez simuler des dépendances et autres.

Conclusion: je propose un ensemble de fonctions divisées en modules d'organisation, mais aucun objet.

Considérons un bouton sur une interface graphique. Il a l'état (c'est la taille, la couleur, la position, l'étiquette, etc.). Des choses peuvent lui arriver (c'est cliqué, il faut redessiner, etc.). Dans de telles situations, la modélisation en tant qu'objet a du sens. En tant qu'objet, il peut contenir son état, un ensemble d'actions pouvant être effectuées sur celui-ci (méthodes) et informer les autres parties de l'application que des événements lui ont été causés.

La POO est un excellent outil pour gérer les interfaces graphiques et autres situations dans lesquelles des parties du système ont un état volatile.

D'autres situations, telles que celle que vous décrivez, dans laquelle les données sont lues à partir d'une source, traitées et écrites dans 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 tend à être à la fois plus facile à lire et plus court que les solutions POO.

Tout comme un marteau et une scie sont des outils puissants utilisés correctement, de même que les techniques de programmation orientée objet et déclaratives. 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 des données avec des objets. 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'états ou si j'ai besoin d'une interaction de l'utilisateur, j'utilise des objets. sinon j'utilise (pur et d'ordre supérieur, si possible) des fonctions.

La programmation orientée objet ajoute quatre nouveaux outils à votre arsenal:

1. Encapsulation
2. Abstraction
3. Héritage
4. Polymorphisme

Vous utiliseriez la programmation orientée objet dans votre application lorsqu'elle est devenue suffisamment grande et complexe pour bénéficier de ces outils.

Cette question me semble un peu confuse. Si vous écrivez en Python, vous utiliserez sûrement des objets. Lorsque vous ouvrez un fichier, il retourne un objet. Lorsque vous donnez un résultat, il retourne un objet itérateur. Chaque fonction que vous créez est un objet. Remettre en cause la valeur de OO dans les applications Python semble pour le moins étrange.

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 le lambda (tout comme Java et tout autre nombre de langues généralement décrites comme étant OO), mais il est volontairement simpliste par rapport à un vrai langage fonctionnel.

Peut-être que ces distinctions entre la conception OO et la conception fonctionnelle deviennent obsolètes. Si je crée prends une fonction polymorphe sur un objet conçu par OO et passe un pointeur sur cette fonction sur un objet en tant que paramètre pour une fonction de style fonctionnel *, s'agit-il de OO ou est-il fonctionnel? Je pense que ce sont les deux et aussi une approche très efficace pour résoudre les problèmes.

Je pense que la vraie question est «quand faut-il commencer à concevoir ses propres classes plutôt que de créer un module avec des fonctions? Je pense que la bonne réponse à cela est: quand cela aide à simplifier la solution. Je donnerais la même réponse de base pour n'importe quel 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'un des principaux avantages de la programmation orientée objet est qu'au lieu de raisonner sur le déroulement d'un programme, vous commencez à raisonner sur un état.

Bien souvent, je vois l'objet, je vois les méthodes, mais ce que je vois aussi, c'est que le moteur du code est le flux plutôt que l'état.

Et une fois que vous vous interrogez sur l'état, il est facile de créer un bon code POO car dès que votre code devient trop complexe, vous remarquez que vous ne pouvez plus raisonner à propos de votre état et que vous savez qu'il est nécessaire de refactoriser.

Prenons votre exemple: vous souhaitez analyser un fichier csv. D'où vient-il: un fichier sur disque. Vous le chargez et le mettez en mémoire et analysez-le. Maintenant, votre client arrive: hé, je veux aussi analyser les fichiers du Web. Vous êtes donc content parce que vous avez créé une interface agréable pour le chargement de votre fichier et que vous ne devez créer que 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 pour cela.

En termes simples:

• Vous pouvez utiliser OOP ou non-OOP dans tout type de projet que vous souhaitez.
• La POO n'est pas la panacée, mais elle aide à gérer la complexité.
• Cela va au-delà de la modularité, il s'agit de compartimenter. 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, il est donc plus facile de localiser les bogues puisqu'il n'existe qu'un ensemble défini de moyens permettant aux différents composants d'un programme de communiquer.
• Dans un programme, beaucoup de choses fonctionnent: variables, constantes, méthodes, fichiers, paramètres, fonctions, modules, etc. Ils peuvent interagir les uns avec les autres d'une manière parfois imprévisible. La POO est un ensemble de principes qui réduisent le nombre de façons dont les choses peuvent interagir les unes avec les autres. Vous n'êtes pas obligé d'utiliser la POO pour le faire, mais cela aide.

Cela dit, il y a d'autres facteurs à prendre en compte:

• Vos programmeurs sont-ils compétents en POO / OOD?
• Vos programmeurs maîtrisent-ils un langage POO?
• Pensez-vous que le logiciel va devenir complexe avec le temps?
• Envisagez-vous de redimensionner 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 croître ou comme base pour des projets futurs?

Ne vous méprenez pas: vous pouvez réaliser tout cela sans utiliser la POO, mais avec la POO, ce sera plus facile.

Mais...

Si votre équipe n'est pas compétente en POO / OOD et n'a aucune expertise dans ce domaine, utilisez les ressources que vous avez.

Ma question serait donc la suivante: comment savez-vous / décidez-vous quand utiliser la POO dans une application?

Toujours l'utiliser. Une fois que vous en aurez l'habitude, vous l'utiliserez pour tout. C'est un excellent moyen de garantir une bonne abstraction entre les capacités et leur utilisation, ce qui constitue un avantage important pour la maintenance. Nous l'utilisons, par exemple, pour

• Les petits objets de structure de données, car ils sont souvent polymorphes, par exemple, et la structure de données intermédiaire après l'analyse syntaxique comporte souvent plusieurs petites entités, qui ont un comportement commun mais sont également spécialisées. C’est un excellent cas d’utilisation pour une classe ou une interface de base commune, avec des implémentations et des comportements spécialisés, c’est-à-dire une hiérarchie de classes (polymorphisme).

• l'enregistrement, par exemple, car il est facile de remplacer un autre enregistreur

• éléments volumineux de la structure du programme, parce que vous créez plusieurs concurrents, et peut-être tirer parti des processeurs multi-cpu. Par exemple, un serveur Web peut facilement utiliser plusieurs gestionnaires de demandes simultanés, en raison d'objets.

Comme je le disais plus tôt, cela facilite la refactorisation et la réutilisation, ce qui favorise une bonne abstraction, ce qui facilite la maintenance. La POO devrait être adoptée et utilisée tout le temps. Une bonne programmation POO évite les méthodes statiques et / ou les données statiques et utilise des objets pour tout.

La programmation orientée objet fournit des outils pour créer un cadre. Ces outils sont l’encapsulation, l’abstraction, l’héritage et le polymorphisme. Ces idées vous aideront à diviser votre programme en deux parties.

How to - C’est la partie travail du cadre de votre code, dans laquelle vous créez une sorte d’abstraction, décidez du fonctionnement de vos blocs en général et de la manière dont il interagit avec d’autres blocs.

Quoi faire - Cette partie est l'endroit où les blocs effectuent le travail proprement dit. Ici, les classes sont dérivées des classes de base créées dans la section "Comment procéder".

On peut grandement bénéficier de OOPS

1. si vous pouvez réutiliser un cadre existant et que vous n’avez qu’à implémenter des détails spécifiques dans la section "que faire".
2. La fonctionnalité mise en œuvre pour le projet actuel est générique / couramment utilisée. D'autres projets / projets futurs peuvent tirer parti du cadre créé pendant le développement du projet en cours.
3. Décomposer des projets énormes en modèles connus pour résoudre un gros problème.
4. Utilisez OOPS, même pour un petit projet, pour prendre l'habitude de l'utiliser et soyez prêt lorsque 1 à 3 types de problèmes surviennent