La POO devient-elle plus facile ou plus difficile? [fermé]


36

Lorsque les concepts de programmation orientée objet ont été présentés aux programmeurs il y a quelques années, cela semblait intéressant et la programmation était plus propre. OOP était comme ça

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

C'était plus facile à comprendre avec un nom auto-descriptif.

Mais maintenant, la POO, avec des motifs tels que les objets de transfert de données, les objets de valeur, le référentiel, l'injection de dépendance, etc., est devenue plus complexe. Pour atteindre ce qui précède, vous devrez peut-être créer plusieurs classes (par exemple, abstract, factory, DAO, etc.) et implémenter plusieurs interfaces.

Remarque: je ne suis pas contre les meilleures pratiques qui facilitent la collaboration, les tests et l'intégration.


23
Créer une bonne architecture logicielle a toujours été difficile et le sera (probablement) toujours.
johannes

6
Je renommerais addItempour addet removeItempour remove. Parce que c'est plus facile à lire. stock.add(item)ou stock.remove(item). Et plus orienté POO.
Razpeitia

1
La POO originale ne ressemblait presque pas à ce que vous avez montré. La programmation orientée objet ne concerne pas la syntaxe , mais une sorte d'abstraction popularisée par Smalltalk. Cela ne prouve pas nécessairement que votre point de vue est faux, et la prémisse n'est pas défectueuse; c'est encore plus vrai que vous ne le réalisez.
Konrad Rudolph

1
si vous comparez des pommes et des oranges, selon votre logique, la programmation impérative (c.-à-d. boucles et if-condition) est plus simple que tout ce que nous avons aujourd'hui. La programmation impérative est la pierre angulaire des classes / POO et les classes / POE sont les blocs de construction des modèles de conception. Les choses deviennent plus complexes à mesure que vous avancez, car vous résolvez des problèmes plus complexes.
Lie Ryan

2
@LieRyan - J'ai vu des problèmes devenir complexes simplement parce que personne en charge n'a été capable de les résoudre avec une programmation impérative simple et les a attaqués avec des modèles de conception au dessus de la POO en plus de la solution impérative simple qui aurait dû être mise en œuvre seule.
mouviciel

Réponses:


35

La POO elle-même n'a pas beaucoup changé depuis sa création. Quelques nouveaux angles ont été explorés, mais les principes fondamentaux restent les mêmes. Au contraire, les connaissances collectives accumulées au fil des ans rendent la vie du programmeur plus facile que compliquée. Les modèles de conception ne sont pas un obstacle; ils fournissent une boîte à outils de solutions aux problèmes standard, distillés par des années et des années d'expérience.

Alors, pourquoi percevez-vous la POO aujourd'hui plus complexe que lorsque vous avez commencé à l'utiliser?

L'une des raisons peut être que le code auquel vous êtes exposé devient plus complexe - non pas parce que la POO est devenue plus complexe, mais parce que vous avez progressé dans l'échelle d'apprentissage et que vous devez lire des bases de code plus grandes et plus complexes.

Une autre raison peut être que, même si le paradigme de la complexité n'a pas changé, la taille et la complexité d'un projet logiciel moyen peuvent très bien avoir. Avec une puissance de traitement disponible sur les téléphones portables de niveau client qui aurait été un rêve fou pour un développeur sur un serveur il y a moins de deux décennies, le grand public s'attend en gros à une interface graphique animée épurée, même pour l'application la moins chère, et à des ordinateurs de bureau d'entrée de gamme plus puissants. qu’un "superordinateur" des années 1980, il est tout à fait naturel que la barre ait été relevée depuis les débuts de Smalltalk et de C ++.

Et puis, il y a le fait que dans les applications modernes, la concurrence et le parallélisme sont la norme plutôt que l'exception, et les applications ont souvent besoin de communiquer entre différentes machines pour générer et analyser tout un zoo de protocoles. Bien que la POO soit un excellent paradigme organisationnel, elle a ses limites, comme tout autre paradigme: par exemple, elle ne fournit pas beaucoup d’abstraction pour la concurrence (la plupart des implémentations étant plus ou moins une réflexion ultérieure, ou totalement externalisées aux bibliothèques). , et ce n’est pas la meilleure approche possible pour construire des analyseurs syntaxiques et transformer des données. La programmation moderne rencontre fréquemment les limites du paradigme de la programmation orientée objet et les modèles de conception ne peuvent vous mener que loin. (Personnellement, Je considère que le fait que nous ayons besoin de modèles de conception en est un signe: si le paradigme fournissait ces solutions immédiatement, il serait plus expressif pour ces problèmes et les solutions standard seraient évidentes. Il n'y a pas de modèle de conception permettant de décrire l'héritage de méthode, car il s'agit d'une fonctionnalité essentielle de la programmation orientée objet; mais il existe un modèle d'usine, car la POO ne fournit pas un moyen naturel évident de construire des objets de manière polymorphe et transparente.)

De ce fait, la plupart des langages POO modernes intègrent des fonctionnalités issues d'autres paradigmes, ce qui les rend plus expressifs et plus puissants, mais également plus complexes. C # en est le principal exemple: il a des racines évidentes de POO, mais des fonctionnalités telles que les délégués, les événements, les types de données variantes, les attributs, les fonctions anonymes, les expressions lambda, les génériques, etc., sont issues d'autres paradigmes, notamment de la programmation fonctionnelle. .


Les modèles de conception ont donc ajouté à la complexité. Les modèles de conception de sens ne sont pas nécessairement de la POO mais sont ajoutés pour améliorer la POO.
tunmise fasipe

@tunmisefasipe: Pas tout à fait. Les modèles de conception ne sont que des solutions éprouvées aux problèmes standard; ils ne sont pas un «ajout» à la POO, mais une conséquence. La complexité était déjà là; les modèles de conception fournissent simplement des stratégies de livre de cuisine pour y remédier.
tdammers

17

Non, cela devient de plus en plus technique. Et vous avez raison: dans le chat SO C ++, nous plaisantons souvent à propos des AbstractSingletonFactoryProxyBeanBridgeAdapterManagers que nous voyons dans le code Java.

Mais bon code ne présente pas cette propriété. En bon code, vous pouvez toujours dire

std::stack<int> s;
s.push(5);
s.pop();

4
Ce n'est pas clair dans votre message, mais je pense que la sur-ingénierie est évidente à la fois en code Java et en C ++. Ce n'est pas une propriété de l'une ou l'autre langue en soi, mais de la pratique des programmeurs ... Les deux langues permettent d'écrire un bon code, bien qu'aucune des deux (IMO) ne soit particulièrement adaptée à celui-ci :) Les frameworks en Java sont vraiment nul, malheureusement.
Andres F.

12
À propos d'ingénierie excessive
Sécurisé

3
@AndresF. C'est vrai, mais vous semblez ne pas en obtenir autant en code C ++, contrairement à Java et .NET: il suffit de regarder le modèle de conception de MVVMVMMD msdn.microsoft.com/en-us/magazine/hh965661.aspx as Voici un exemple de la façon dont vous prenez du "code simple" et placez un motif sur celui-ci pour le rendre "plus facile", puis sur un autre motif sur le motif car le motif d'origine n'était pas aussi simple que annoncé. La sur-ingénierie devient de plus en plus courante.
gbjbaanb

5
Je discuterais avec le "devenir" peu. La sur-ingénierie est aussi ancienne que l'ingénierie.
Gort le robot

4
@AndresF. Nous sommes particulièrement anti-Java dans le chat, mais il est vrai que Java, plus que le C ++ , encourage la sur-ingénierie car il le rend plus abordable (GC), et les bibliothèques Java d'entreprise populaires ont popularisé ce style, comme vous l'avez noté. toi même.
Konrad Rudolph

10

Je dirais que les problèmes de "complexité" que vous avez mentionnés n’ont rien à voir avec la programmation orientée objet. Cela a plus à voir avec la séparation des préoccupations.

Il y a de nombreuses années, j'ai travaillé sur un système dans lequel la classe de domaine avait la responsabilité de se charger elle-même à partir de la base de données, par exemple:

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

C'est un code très clair. Pas de problème pour comprendre cela. Le problème serait toutefois dans l'unité qui teste le code. À savoir, comment pourrais-je tester la Userclasse sans avoir à en charger une à partir de la base de données? Et comment pourrais-je tester ce code de traitement des demandes Web sans avoir accès à la base de données? Ce n'est tout simplement pas possible.

C'est pourquoi nous avons un modèle semblable à un référentiel, qui sépare la responsabilité de la gestion de la logique de domaine d'un utilisateur de la fonctionnalité de chargement et de sauvegarde effectifs dans un magasin de données. IOC aide à réduire le couplage, en rendant le code plus vérifiable, etc.

Donc, si nous revenons à l'exemple que vous écrivez, que feriez-vous avec le stock après l'avoir créé? Enregistrez-le dans la base de données

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

Le rouge! Il n'y a pas de mouvement dans la progression de la POO suggérant que cela devrait être plus difficile. Malheureusement, si vous choisissez d'utiliser un mappeur OR pour votre code d'accès aux données, vous pouvez être confronté au problème suivant: le mappeur OR impose des restrictions sur la manière d'écrire votre système. Mais c'est une autre affaire.

Si vous êtes nouveau dans ces modèles, vous devrez peut-être apprendre un nouveau style de programmation. Mais ce style de programmation n’est en aucun cas plus dur que la programmation POO à l’école.


Vous connaissez les efforts que vous devez déployer pour configurer votre référentiel. Bien que, après l'avoir installé, il devienne réutilisable.
tunmise fasipe

peut-être que le problème vient des tests unitaires. Si nous avions de meilleurs outils pour tester le tout (comme vous devez le faire de toute façon) au lieu de minuscules morceaux, nous aurions des systèmes qui contiendraient moins de bugs?
gbjbaanb

2
@gbjbaanb: nous l'avons déjà, il s'appelle intégration / test fonctionnel. Les tests unitaires ont un but différent mais tout aussi nécessaire
Kevin

@gbjbaanb - Nous disposons déjà d'excellents outils pour les tests d'acceptation à l'échelle du système, tels que Cucumber on the Rails. Mais les équipes qui sont vraiment bonnes et écrivent très peu de bugs, mais livrent aussi rapidement, elles écrivent beaucoup de tests unitaires et quelques tests à l’échelle du système. Voir sur le « triangle d' essai », par exemple ici jonkruger.com/blog/2010/02/08/the-automated-testing-triangle
Pete

4

Ni. Nos problèmes n'ont pas vraiment changé. la barre du code acceptable a été levée.

Pour atteindre ce qui précède, vous devrez peut-être créer plusieurs classes (par exemple, abstract, factory, DAO, etc.) et implémenter plusieurs interfaces.

Vous ne devez le faire. Mais si vous ne le faites pas alors les problèmes surgissent; problèmes qui ont toujours été là. Cependant, les programmeurs ont suffisamment d'expérience pour identifier ces problèmes et fournir des mécanismes pour les résoudre (si nécessaire). Nous en apprenons plus à ce sujet et trouvons de meilleures solutions (voir - le point de vue des programmeurs sur le singleton, par exemple).

Mais vous devez aussi comprendre que présenter les programmeurs à OO (ou quelque chose de ce genre) aura tendance à passer sous silence les circonstances exceptionnelles. Il est tout simplement plus facile d'expliquer le bon chemin et de s'inquiéter du reste une fois que les débutants l'ont compris. Il n'y a pas de solution miracle. alors oui, je suppose que les choses sembleront toujours plus difficiles quand cette illusion idyllique est brisée ...


3

Les exemples "d'introduction à OO" sont beaucoup plus simples qu'une application réelle. Vous n'avez besoin que d'une classe pour atteindre ce qui précède. Le problème est que cela ne fait pas grand chose. Certains modèles de conception tentent de se rapprocher (comme ActiveRecord). Mais, au final, tout exemple non trivial aura plus d'une classe; c'est ok.


Notez également que les frameworks se construisent avec le temps. Alors oui, la programmation nécessite plus de connaissances. Cela signifie également que l'on peut faire plus en moins de temps.
Jeanne Boyarsky

3

Les langages de programmation qui utilisent OO aujourd'hui essaient de répondre aux exigences complexes et aux environnements en constante évolution. OO permet à ses utilisateurs de masquer divers niveaux de complexité (entre autres), de sorte que le codage devienne plus clair et plus facile à construire et à comprendre. Cependant, cette fonctionnalité n'est pas toujours prête à l'emploi. Dans votre exemple, OO vous a permis de me cacher certains détails en fournissant une méthode pour gérer les éléments d'une collection et peut même même la conserver en utilisant la méthode "AddItem". Consacrer des efforts pour masquer la complexité peut aboutir à un cadre facile à utiliser et réutilisable qui simplifie la vie. Par exemple, de nombreuses implémentations ORM vous permettent de communiquer avec des bases de données sans que le programmeur écrive les détails SQL. C'est en effet puissant et le rend plus simple pour le développeur.

Les modèles que vous évoquez ne sont que cela. Ils sont censés vous faciliter la vie. Mais c'est à vous de les adopter et de les ajuster. Le fait que plus de travail soit requis est simplement parce que vous obtenez plus d'avantages. C'est comme payer plus pour une Ferrari. Si vous voulez les extras, vous les payez. Par conséquent, si vous décidez de créer une solution N-Tier évolutive pouvant être exécutée sur plusieurs serveurs et différentes bases de données back-end, cela aura un coût. Si votre application ne nécessite pas cette complexité, ignorez les éléments supplémentaires et utilisez la solution la plus simple qui répond à vos besoins (KISS & YAGNI).

Donc, pour conclure, je ne pense pas que la POO en tant que concept devienne de plus en plus complexe, nous, les utilisateurs de la POO avons le choix de l’utiliser de différentes manières, et c’est une bonne chose.


Points clairs. Je connais YAGNI. Qu'est-ce que KISS?
tunmise fasipe

2
@tunmisefasipe, KISS est un nom court pour un principe de conception. Les mots originaux sont "Keep It Simple (Stupid)" (ref: en.wikipedia.org/wiki/KISS_principle ) mais un phrasé plus poli pourrait être "Keep It So Simple".
NoChance

3
@tunmisefasipe - KISS = Keep It Simple, Stupid. Une phrase que je me répète OVER, OVER, OVER, et elle ne semble toujours pas
pénétrer

@ MichaelKohne, nous le faisons tous! Je suppose que c'est un art de pouvoir simplifier les choses. E = M C C en dit beaucoup sous une forme très concise!
NoChance

3

Réponse courte : Oui, parce que vous traitez des problèmes plus difficiles.

Réponse longue (fortement biaisée) : Pour moi, les modèles de conception indiquent généralement que certains paradigmes ont des problèmes dans une zone donnée. Les modèles de POO traitent des problèmes de POO (à un niveau inférieur, les modèles de Java traitent de problèmes de Java), les modèles de PF traitent des problèmes de FP, etc.

Pendant la programmation, vous pouvez avoir des priorités différentes. Vous voudrez peut-être un programme correct, vous voudrez peut-être des délais de commercialisation plus courts, un programme le plus rapide possible, une maintenabilité à long terme ou une maintenabilité instantanée par un nouvel employé. Selon le type de broussailles dans lequel vous vous trouvez, vous aurez énormément de choses différentes - si vous programmez un contrôleur de centrale électrique, vous voulez le faire correctement du premier coup et ne pas corriger le bogue à tout moment ("Est-ce que la fusion se produit à chaque fois que vous appuyez sur Ctrl+Alt+Del?"). Si vous êtes dans HPC, la logique peut être relativement simple, mais vous voulez l'exécuter aussi rapidement que possible, etc.

La POO est dans une certaine mesure "trop ​​bonne" dans des cas simples et c'est une "histoire réelle en direct". Par exemple dans le premier livre sur POO j'ai lu , il y avait des classes Person, Employeeet Manageravec is-arelation. Jusqu'ici tout va bien, mais que se passe-t-il si l'employé est promu au poste de gestionnaire?

D’un autre côté, d’autres paradigmes ont des leçons plus difficiles lors de la première utilisation - par exemple, la PF avec des variables immuables (ce qui est drôle, c’est que les personnes qui ont déjà expérimenté la programmation ont souvent plus de difficultés à apprendre que celles pour qui c’est la première langue). pas plus dur que la POO. Tester des fonctions pures est trivial et dans Haskell / Scala / ... vous avez des outils qui génèrent des tests pour vous.

PS Oui, la réponse est biaisée contre la POO et j’admets qu’elle est «en réaction» à la POO. OOP a ses utilisations mais ce n'est pas la seule solution ultime à mon avis.

PPS. Oui, utilisez des modèles de conception: ils simplifient la programmation POO.

PPPS. J'ai utilisé la programmation orientée objet comme synonyme de programmation impérative pour la programmation orientée objet.


2

Je pense que c’est davantage un cas de documents et d’exemples qui deviennent plus réalistes.

Les premiers livres POO (en particulier les premiers livres Java) présentaient une vue absurdement simplifiée de la programmation d'applications. Les exemples "Débitez un compte bancaire avec un programme Java à 10 lignes" ont toujours été particulièrement agaçants, car j’ai vu des exemples concrets de cette tâche simple fonctionnant à 6000 lignes de code COBOL (et à une tentative de remplacement de Java exécutée à 3500 lignes avant son abandon. comme irréalisable!).

Heureusement, les livres OO ont maintenant tendance à reconnaître les complexités de la vie réelle et à fournir des exemples utiles sur la façon de les gérer.

Mais si vous voulez savoir comment gérer un compte bancaire en seulement 15 lignes de programmation fonctionnelle, votre code

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.