Quand la POO est-elle mieux adaptée ?[fermé]

https://stackoverflow.com/questions/6703

08-06-2019
|

Question

Depuis que j'ai commencé à étudier la programmation orientée objet, je lis fréquemment des articles/blogs disant que les fonctions sont meilleures ou que tous les problèmes ne doivent pas être modélisés sous forme d'objets.D’après vos aventures personnelles en programmation, quand pensez-vous qu’un problème est mieux résolu par la POO ?

La solution

Il n’y a pas de règle absolue.Un problème est mieux résolu avec la POO lorsque vous êtes meilleur pour résoudre les problèmes et penser selon une mentalité OO.L'orientation objet n'est qu'un autre outil apparu en essayant de faire de l'informatique un meilleur outil pour résoudre des problèmes.

Cependant, cela peut permettre une meilleure réutilisation du code et peut également conduire à un code plus soigné.Mais bien souvent, ces qualités tant vantées n’ont en réalité que peu de valeur réelle.L’application des techniques OO à une application fonctionnelle existante pourrait en réalité poser de nombreux problèmes.La compétence consiste à apprendre de nombreuses techniques différentes et à appliquer la plus appropriée au problème à résoudre.

OO est souvent cité comme une solution de type Nirvana pour le développement de logiciels, mais il arrive souvent qu'il ne soit pas approprié de l'appliquer au problème en question.Cela peut, bien souvent, conduire à une ingénierie excessive d’un problème pour parvenir à la solution parfaite, alors que cela n’est souvent vraiment pas nécessaire.

Essentiellement, la POO n'est pas vraiment une programmation orientée objet, mais mappe la pensée orientée objet à un langage de programmation capable de prendre en charge les techniques OO.Les techniques OO peuvent être prises en charge par des langages qui ne sont pas intrinsèquement OO, et il existe des techniques que vous pouvez utiliser dans les langages fonctionnels pour profiter de leurs avantages.

À titre d'exemple, je développe des logiciels OO depuis environ 20 ans maintenant, j'ai donc tendance à penser en termes OO lorsque je résout des problèmes, quelle que soit la langue dans laquelle j'écris.Actuellement, j'implémente le polymorphisme en utilisant Perl 5.6, qui ne le prend pas en charge nativement.J'ai choisi de faire cela car cela fera de la maintenance et de l'extension du code une simple tâche de configuration, plutôt qu'un problème de développement.

Je ne sais pas si cela est clair.Il y a des gens qui sont durs dans le tribunal OO, et il y a des gens qui sont durs dans le tribunal fonctionnel.Et puis il y a des gens qui ont essayé les deux et essaient de tirer le meilleur de chacun.Ni l’un ni l’autre n’est parfait, mais les deux ont de très bonnes caractéristiques que vous pouvez utiliser quelle que soit la langue.

Si vous essayez d'apprendre la POO, ne vous concentrez pas uniquement sur la POO, mais essayez d'utiliser l'analyse orientée objet et les principes généraux de l'OO pour l'ensemble du spectre de la solution du problème.

Autres conseils

Je suis un ancien, mais je programme également la POO depuis longtemps.Je suis personnellement contre l'utilisation de la POO juste pour l'utiliser.Je préfère que les objets aient des raisons d'exister précises, qu'ils modélisent quelque chose de concret et qu'ils aient du sens.

Le problème que j'ai avec beaucoup de nouveaux développeurs est qu'ils n'ont aucune idée des ressources qu'ils consomment avec le code qu'ils créent.Lorsque vous traitez une grande quantité de données et accédez à des bases de données, le modèle objet « parfait » peut être la pire chose que vous puissiez faire en termes de performances et de ressources.

Mon résultat est que si cela a du sens en tant qu'objet, programmez-le en tant qu'objet, à condition que vous considériez l'impact sur les performances/ressources de la mise en œuvre de votre modèle objet.

Je pense que cela convient mieux lorsque vous modélisez quelque chose de cohérent avec l'état et les actions associées sur ces états.Je suppose que c'est un peu vague, mais je ne suis pas sûr qu'il y ait une réponse parfaite ici.

Le problème avec la POO est qu'elle vous permet d'encapsuler et d'abstraire des données et des informations, ce qui est une véritable aubaine pour la construction d'un grand système.Vous pouvez faire la même chose avec d’autres paradigmes, mais il semble que la POO soit particulièrement utile dans cette catégorie.

Cela dépend aussi de la langue que vous utilisez.S'il s'agit d'un langage avec un support riche en POO, vous devriez probablement l'utiliser à votre avantage.Si ce n’est pas le cas, vous devrez peut-être trouver d’autres mécanismes pour vous aider à diviser le problème en éléments plus petits et facilement testables.

Je suis vendu à la POO.

Chaque fois que vous pouvez définir un concept pour un problème, il peut probablement être enveloppé dans un objet.

Le problème avec la POO est que certaines personnes en ont abusé et ont rendu leur code encore plus difficile à comprendre.Si vous faites attention à ce que vous mettez dans les objets et à ce que vous mettez dans les services (classes statiques), vous bénéficierez de l'utilisation d'objets.

Ne mettez simplement pas quelque chose qui n'appartient pas à un objet dans l'objet, car vous avez besoin que votre objet fasse quelque chose de nouveau auquel vous n'aviez pas pensé au départ, refactorisez et trouvez le meilleur moyen d'ajouter cette fonctionnalité.

Il existe 5 critères pour savoir si vous devez privilégier le code orienté objet plutôt que le code basé sur objet, fonctionnel ou procédural.N'oubliez pas que tous ces styles sont disponibles dans toutes les langues, ils sont modes.Tous ces éléments sont écrits dans le style « Dois-je privilégier OO dans cette situation ? »

Le système est très complexe et a plus de 9 000 LOC (juste un niveau arbitraire).-- À mesure que les systèmes deviennent plus complexes, les avantages obtenus en encapsulant la complexité augmentent considérablement.Avec OO, contrairement aux autres techniques, vous avez tendance à encapsuler de plus en plus de complexité, ce qui est très précieux à ce niveau.Les méthodes basées sur des objets ou procédurales doivent être privilégiées avant cela.(Ceci ne préconise pas une langue particulière, remarquez. OO C correspond plus à ces fonctionnalités que OO C++ dans mon esprit, un langage avec une réputation notoire pour ses abstractions qui fuient et une capacité à manger des magasins avec même 1 programmeur médiocre/obstiné pour le déjeuner).

Votre code n'est pas des opérations sur des données (c'est-à-direBasé sur une base de données ou basé sur des mathématiques/analyses).Le code basé sur une base de données est souvent plus facilement représenté via un style procédural.Le code basé sur l’analyse est souvent plus facile à représenter dans un style fonctionnel.

Votre modèle est une simulation de quelque chose (OO excelle dans les simulations).

Vous faites quelque chose pour lequel la répartition des sous-types basés sur les objets de OO est précieuse (c'est-à-dire que vous devez envoyer un message à tous les objets d'un certain type et de divers sous-types et obtenir une réaction appropriée, mais différente, de chacun d'eux) .

Votre application n’est pas multithread, en particulier dans une base de code de type méthode de tâche non-travailleur.OO est assez problématique dans les programmes multithreads et nécessitent différents threads pour effectuer différentes tâches.Si votre programme est structuré avec un ou deux threads principaux et de nombreux threads de travail faisant la même chose, le flux de contrôle confus des programmes OO est plus facile à gérer, car tous les threads de travail seront isolés dans ce qu'ils touchent et peuvent être considérés comme une section monolithique de code.Considérez en fait n’importe quel autre paradigme.Functional excelle dans le multithreading (l'absence d'effets secondaires est une énorme aubaine), et la programmation basée sur les objets peut vous apporter des avantages avec une partie de l'encapsulation de OO, mais avec un code procédural plus traçable dans les sections critiques de votre base de code.Bien entendu, la procédure excelle également dans ce domaine.

Certains endroits où OO n'est pas si bon sont ceux où vous avez affaire à des "ensembles" de données comme dans SQL.OO a tendance à rendre les opérations basées sur des ensembles plus difficiles car il n'est pas vraiment conçu pour prendre de manière optimale l'intersection de deux ensembles ou le sur-ensemble de deux ensembles.

De plus, il y a des moments où une approche fonctionnelle aurait plus de sens, comme dans cet exemple tiré de MSDN:

Pensez, par exemple, à écrire un programme pour convertir un document XML en une autre forme de données.Bien qu'il soit certainement possible d'écrire un programme C# qui analyse le document XML et applique diverses instructions if pour déterminer les actions à entreprendre à différents points du document, une approche sans doute supérieure consiste à écrire la transformation sous forme de feuille de style extensible. Programme de transformation du langage (XSLT).Sans surprise, XSLT contient une grande part de fonctionnalisme.

Je trouve qu'il est utile de penser à un problème donné en termes de « choses ».

Si le problème peut être considéré comme ayant une ou plusieurs « choses », où chaque « chose » a un certain nombre d'attributs ou d'informations qui font référence à son état, et un certain nombre d'opérations qui peuvent être effectuées dessus - alors la POO est probablement la voie à suivre !

La clé pour apprendre la programmation orientée objet est l’apprentissage du modèle de conception.En vous renseignant sur les modèles de conception, vous pourrez mieux voir quand les cours sont nécessaires et quand ils ne le sont pas.Comme tout ce qui est utilisé en programmation, l'utilisation des classes et autres fonctionnalités des langages POO dépend de votre conception et de vos exigences.Comme les algorithmes, les modèles de conception sont un concept de niveau supérieur.

Un modèle de conception joue un rôle similaire à celui des algorithmes pour les langages de programmation traditionnels.Un modèle de conception vous indique comment créer et combiner un objet pour effectuer une tâche utile.Comme les meilleurs algorithmes, les meilleurs modèles de conception sont suffisamment généraux pour pouvoir être appliqués à une variété de problèmes courants.

À mon avis, il s’agit plutôt de vous en tant que personne.Certaines personnes pensent mieux en termes fonctionnels et d'autres préfèrent les classes et les objets.Je dirais que la POO est mieux adaptée lorsqu'elle correspond à votre modèle mental interne (subjectif) du monde.

Le code orienté objet et le code procédural ont des points d'extensibilité différents.Les solutions orientées objet facilitent l'ajout de nouvelles classes sans modifier les fonctions existantes (voir le principe ouvert-fermé), tandis que le code procédural vous permet d'ajouter des fonctions sans modifier les structures de données existantes.Très souvent, différentes parties d’un système nécessitent des approches différentes selon le type de changement anticipé.

OO permet à la logique liée à un objet d'être placée dans un seul endroit (la classe ou l'objet) afin qu'elle puisse être découplée et plus facile à déboguer et à maintenir.

Ce que j'ai observé, c'est que chaque application est une combinaison d'OO et de code procédural, où le code procédural est le ciment qui lie tous vos objets entre eux (à tout le moins, le code de votre fonction principale).Plus vous pourrez transformer votre code procédural en OO, plus il vous sera facile de maintenir votre code.

Pourquoi la POO est utilisée pour la programmation :

Sa flexibilité – La POO est vraiment flexible en termes d’implémentations d’utilisation.
Cela peut réduire vos codes sources de plus de 99,9 % – cela peut sembler exagérer, mais c’est vrai.
Il est beaucoup plus facile de mettre en œuvre la sécurité – Nous savons tous que la sécurité est l’une des exigences vitales en matière de développement Web.L'utilisation de la POO peut faciliter la mise en œuvre de la sécurité dans vos projets Web.
Cela rend le codage plus organisé – Nous savons tous qu’un programme propre est un codage propre.Utiliser la POO au lieu de la procédure rend les choses plus organisées et systématisées (évidemment).
Cela aide votre équipe à travailler facilement les uns avec les autres – je sais que certains d’entre vous ont eu/ont vécu des projets d’équipe et certains d’entre vous savent qu’il est important d’avoir la même méthode, les mêmes implémentations, les mêmes algorithmes, etc.

Cela dépend du problème :le paradigme POO est utile dans la conception de systèmes ou de frameworks distribués avec de nombreuses entités vivant pendant les actions de l'utilisateur (exemple :application Web).

Mais si vous avez un problème en mathématiques vous préférerez un langage fonctionnel (LISP) ;pour les systèmes critiques en termes de performances, vous utiliserez ADA ou C, etc.

Le langage POO est utile car il utilise également probablement le garbage collector (utilisation automatique de la mémoire) lors de l'exécution du programme :vous programmez en C beaucoup de temps vous devez déboguer et corriger manuellement un problème de mémoire.

La POO est utile lorsque vous avez des choses.Une socket, un bouton, un fichier.Si vous terminez une classe par er, c'est presque toujours une fonction qui prétend être une classe.TestRunner devrait très probablement être une fonction qui exécute des tests (et probablement nommée run tests).

Personnellement, je pense que la POO est pratiquement une nécessité pour toute application volumineuse.Je ne peux pas imaginer avoir un programme de plus de 100 000 lignes de code sans utiliser la POO, ce serait un cauchemar de maintenance et de conception.

Je vous dis quand la POO est mauvaise.

Lorsque l'architecte écrit du code POO vraiment compliqué et non documenté.Départ à mi-parcours du projet.Et bon nombre de ses éléments de code courants qu'il a utilisés dans divers projets comportent du code manquant.Merci mon Dieu pour .NET Reflector.

Et l’organisation n’exécutait pas Visual Source Safe ou Subversion.

Et je suis désolé.2 pages de code pour se connecter, c'est plutôt ridicule même s'il est joliment en POO....

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow