it-swarm-fr.com

La programmation orientée objet est-elle une solution à la complexité?

Pensez-vous que la programmation orientée objet est une solution à la complexité. Pourquoi? Ce sujet peut être un peu controversé mais mes intentions de connaître la réponse de la raison des références ici!

18
Tony

Il n'y a pas de solution à la complexité.

Dans "le mythique mois mois", Fred Brooks discute de la différence entre la complexité accidentelle et essentielle dans la programmation. La complexité accidentelle est causée par nos outils et méthodes, tels que devoir écrire et tester un code supplémentaire dans une langue, car nous ne pouvons pas exprimer nos idées directement, et des choses comme ça. De nouvelles méthodes et techniques peuvent réduire la complexité accidentelle. Je peux écrire des programmes plus rapidement et mieux que je pouvais vingt-cinq ans, parce que j'ai de meilleures langues et outils.

La complexité essentielle provient du fait que ce que nous essayons de faire de la programmation est intrinsèquement compliqué et qu'il existe une complexité irréductible. "Essentiel", dans ce contexte, signifie "relatif à l'essence de la chose" plutôt que "très nécessaire".

Par conséquent, il a affirmé qu'il n'y aurait pas de balle d'argent, que le logiciel de rédaction continuerait d'être difficile.

Je vous recommande vivement de lire son livre: spécialement, je recommande l'édition d'anniversaire d'argent, avec un essai supplémentaire "Aucune balle d'argent". En cela, il examine les solutions proposées à la complexité et considère leur impact. (Ce qu'il trouve le plus efficace est le logiciel shrink-wrap - écrire quelque chose de complexe une fois et vendre des milliers ou des millions de copies.)

Maintenant, la programmation orientée objet aide, lorsqu'elle est terminée, en créant des abstractions et en cachant la complexité. Un objet d'une classe a un certain comportement défini que nous pouvons raisonner, sans se soucier de la complexité de la mise en œuvre. Les classes correctement écrites ont un faible accouplement entre eux et la division et la conquérie sont un excellent moyen de faire face à la complexité si vous pouvez vous en tirer. Ils ont également une cohésion élevée, en ce sens qu'ils sont un ensemble de fonctions et de données qui se rapportent de très près les unes aux autres.

24
David Thornley

Je m'attends à ce que vous obteniez de meilleures réponses bientôt, mais voici un simple:

OOP aide * avec la complexité en modélisant le logiciel de manière proche de la façon dont nous modélisons tout le reste du monde. Il est généralement plus facile d'imaginer un objet de balle en interaction avec un objet mural qu'il ne s'agit d'imaginer une série de routines et de structures de données pour faire la même chose, car il est plus proche de la façon dont nous interagissons avec le monde réel.

* Parce que rien ne peut "résoudre" la complexité

18
Fishtoaster

Je pense que la définition courante actuelle de OOP n'est pas une bonne solution pour la gestion de la complexité.

Si vous revenez à ses racines, je crois qu'Lan Kay a été influencé par "Lisp" beaucoup.

Étant donné que Lisp n'a pas été corrompue par une adoption traditionnelle, elle a probablement réussi à conserver ses valeurs fondamentales. Je pense donc à voir comment Lisp s'attaque à ce problème de la complexité pourrait nous donner une certaine perspicacité, et nous pouvons l'utiliser comme une base de juge à quel point il est utile OOP à la complexité.

Si vous regardez la fin de la "conférence 3a: Henderson Escher exemple" de [~ # ~ # ~ # ~] , Hal Abelson propose que la complexité soit gérée non plus en brisant la tâche en plus petit sous-tâches, mais en créant des couches d'abstraction. Au plus haut niveau, vous exprimez la solution au problème compliqué en termes de solution au niveau inférieur d'abstraction.

Je pense OOP était-il initialement destiné à créer ces couches d'abstractions.

Malheureusement, de nos jours, OOP est (AB) utilisé pour écrire un code/structures spaghetti.

Je vais constituer un exemple: un jeu multi-joueurs FPS.

Au plus haut niveau, le jeu fonctionne en ayant un groupe de joueurs qui courent autour d'une carte et en tirant les uns des autres en utilisant des armes.

Au niveau inférieur suivant, nous devons parler des cartes et des armes et des joueurs. Peut-être que nous pouvons en parler comme des objets physiques qui interagissent dans le monde du jeu.

Au niveau inférieur suivant, nous pouvons parler de la manière dont les objets interagissent physiquement (mouvement, collisions, etc.).

Et ainsi de suite.

Ce que cela signifie (et je suis en quelque sorte citant de SICP ..), est-ce que, à chaque couche, nous ne résolvons pas seulement un problème spécifique particulier, mais une classe de problèmes qui tombent en quelque sorte dans le quartier du problème que nous " en essayant de résoudre. Donc, s'il y a un petit changement dans la description du problème, cela n'exigerait probablement qu'un petit changement dans la solution.

Donc, la voie sage à utiliser OOP doit créer des couches d'abstractions, à chaque niveau d'abstraction, vous résolvez le problème à l'aide des "objets" à partir du niveau directement ci-dessous.

Voici le peu que je cite la conférence: http://www.youtube.com/watch?v=cytrfncmqhq

15
hasen

Comme d'habitude je suis en désaccord avec tout le monde. Loin de vous donner des outils pour gérer la complexité, OOP Crée une énorme complexité, car c'est un paradigme inadéquat et mathématiquement faux. Il confond les programmeurs sans fin, essayer de modéliser les choses avec OOP qui ne peut pas être modélisé avec OOP.

À mon avis, le travail séminal ici est la construction de logiciels orientés objet de Meyer. Il détaille un ensemble d'exigences, y compris celui que je considère comme crucial: le principe ouvert. Cela dit qu'une chose doit être ouverte pour l'extension mais fermée pour une utilisation, en même temps.

Meyer procède pour dériver l'orientation objet de ces exigences, comme incarné dans Eiffel. L'encapsulation fournit une fermeture, une open-ness de héritage et la "chose" mentionnée est la classe.

Je considère que ce travail est une bonne science parce que Meyer était manifestement fausse, et c'est possible à cause de la qualité de son travail, d'épingler pointer l'erreur et de le réparer.

L'erreur effectue la classe ou le type, l'unité de modularité. C'est faux, et pratiquablement tellement. Même Meyer a reconnu le problème (appelé le problème de la covariance), que OOP Je ne peux pas gérer les relations d'arité supérieures à une (c'est-à-dire OOP fonctionne bien pour les propriétés mais échoue sur les relations binaires). Dans Eiffel, ce problème a abouti à un système de type non sain!

La solution est assez claire. L'unité de modularité doit être plus grande qu'un type unique. Il doit être composé de plusieurs types et les méthodes les relatives.

Il est à peine surprenant que ce modèle d'abstraction soit soutenu par la théorie mathématique de l'abstraction, à savoir la théorie des catégories: les types sont des objets d'une catégorie et des méthodes (fonctions) sont des flèches.

Avec ce modèle, les représentations de plusieurs types sont connues d'un ensemble de fonctions. La représentation est cachée du public, donc c'est l'encaissement, mais nous utilisons des modules, pas des classes.

Le méta-language standard (SML) et OCAML sont basés directement sur ce modèle. OCAML a également des cours et oop: il n'est pas inutile car OOP==== vous envoie des propriétés, une liaison dynamique aka. Toutefois, la plupart des problèmes du monde réel impliquent des relations et des classes à peine surprenantes ne sont pas utilisées beaucoup dans OCAML.

Il est à peine surprenant le héritage n'est guère utilisé dans la bibliothèque de modèles standard C++.

Le fait simple est que OOP=== ne vous donne pas les bons outils pour gérer la complexité, il ne vous donne même pas les outils pour gérer des problèmes vraiment simples, à la place, il a été induit et confondu deux générations de Les programmeurs. Loin d'aider, OOP est la chose la plus diabolique et la plus mauvaise qui s'est produite dans la programmation depuis C, Fortran et Cobol commençaient à se fatiguer.

11
Yttrill

La programmation orientée objet a des racines pouvant être traçées dans les années 1960. En tant que matériel et logiciel devenaient de plus en plus complexes, la facilité de gestion est souvent devenue une préoccupation. Les chercheurs ont étudié les moyens de maintenir la qualité logicielle et de développer une programmation orientée objet en partie pour traiter des problèmes courants en mettant en valeur fortement l'accent sur des unités discrètes et réutilisables de la logique de programmation.

Un programme orienté objet peut ainsi être considéré comme une collection d'objets interagissants, par opposition au modèle classique, dans lequel un programme est considéré comme une liste de tâches (sous-programmes) à effectuer. Dans OOP, chaque objet est capable de recevoir des messages, de traiter des données et d'envoyer des messages à d'autres objets. Chaque objet peut être considéré comme une "machine" indépendante avec un rôle ou une responsabilité distincte. Les actions (ou "méthodes") sur ces objets sont étroitement associées à l'objet lui-même.

http://en.wikipedia.org/wiki/Object-Oriented_programming

Cette séparation des préoccupations, ainsi que d'autres caractéristiques de l'orientation objet telles que le polymorphisme, l'héritage, le passage, le découplage et l'encapsulation, constituent un cadre logique et conceptuel par lequel la complexité des grands programmes peut être gérée de manière très efficace.

6
Robert Harvey

Il existe de nombreux types de complexité pour le développement de logiciels. Au niveau de la programmation, OOP souhaite résoudre la complexité en utilisant des objets et des classes pour modéliser le domaine problématique. Un gourou bien connu a déclaré que la résolution de problèmes ne représente que le problème de sorte que la solution soit la représentation. elle-même. Par conséquent, par abstraction à l'aide de classes, encapsulation à l'aide de modificateurs d'accès et de méthodes, héritage pour spécifier la relation et la réutilisation, la composition dans l'établissement de la relation et la collaboration entre les classes, le polymorphisme afin de simplifier la détermination de différents comportements dans des objets similaires, la complexité peut être géré.

Il existe également d'autres moyens de gérer la complexité logicielle, par exemple, la programmation logique (PRAGOG) et fonctionnelle (HASKELL).

À un niveau supérieur à la programmation, nous avons besoin de modèles de conception et de principes pour guider le POO. Par conséquent OOP== Gestion de la complexité à un niveau faible (codage), tandis que ces méthodologies telles que des motifs de conception et des principes guident la conception de la solution à un niveau supérieur (système et application) et établissent le développement de logiciels et Manipulation de complexités plus gérables.

Pour répondre à votre question, oui, OOP est simplement une solution pour la manipulation de la complexité parmi de nombreuses autres solutions. C'est une solution à un niveau bas. Nous avons besoin de modèles de conception et de principes pour guider OOP dans un niveau supérieur.

2
StartClass0830

Les problèmes complexes ne peuvent pas être rendus plus simples par la technologie, ils ne peuvent être que gérés par la technologie.

OOP est une technologie, un concept et un moyen d'aborder un problème.

OOP vous donne les outils pour appliquer un conception qui peut faciliter la gestion de la complexité, mais vous pouvez aussi facilement avoir une mauvaise conception qui augmente votre complexité. En d'autres termes, s'il n'est pas utilisé correctement, vous pouvez avoir une complexité induite par la technologie dans vos problèmes.

Gardez à l'esprit qu'il existe de nombreux autres aspects qui dicteront la réussite de votre projet (c'est-à-dire le style de gestion de projet, la définition de problème, la gestion du changement, etc.). La technologie que vous utilisez n'est pertinente que dans combien cela vous aidera-t-il gérer le problème.

À la fin, La programmation orientée objet ne peut pas être une solution à la complexité; c'est juste un outil pour le gérer. (si utilisé correctement)

2
Remus

L'orientation objet (comme classiquement utilisé) est un outil utile dans de nombreuses circonstances, mais ce n'est pas une solution suffisante pour la complexité.

En particulier, il ajoute souvent beaucoup de complexité accidentelle "". Les exemples sont la complexité entourant la mise en œuvre de la mise en œuvre, la nécessité de fournir de nombreuses "fonctionnalités standard" sous forme égale () et de hachage (), etc. Une belle présentation de Stuart Halloway sur ce sujet: " simplicité n'est pas facile "

Les objets dans la plupart des langues ont également tendance à encapsuler beaucoup d'état mutable - qui, dans un monde concomitant, commence de plus en plus à ressembler à une mauvaise décision de conception. Encore une fois une intéressante Video by Rich Hickey examine la distinction entre l'identité d'objet et l'état et comment cela pourrait être une erreur de confondre les deux.

2
mikera

Programmation orientée objet gère la complexité essentielle et optionnelle, mais ne réduit pas non plus.

Je préfère la définition fournie par Eric Steven Raymond dans L'art de la programmation UNIX , car il délimite une complexité essentielle, facultative et accidentelle. http://www.faqs.org/docs/artu/ch13s01.html#id2964646

Le POO ne fait rien pour une complexité essentielle ou facultative, ils fonctionnent les exigences du programme. Cela peut avoir un effet sur la complexité accidentelle, en ce que vous pouvez créer un design plus élégant parfois avec OOP. Parfois Cependant, la conception est pire lorsque vous utilisez OOP.

2
Thomas Langston

Je pense OUI , juste parce que cela vous permet de trancher la complexité dans de petits "blocs de construction" auto-contenant qui masquent les détails, puis utilisez-les pour créer la fonctionnalité Vous avez besoin, étape par étape, couche par couche.

Diviser et conquérir.

1
Miguel Veloso

La programmation orientée objet est une façon de représenter un problème, rien de plus, rien de moins. C'est en soi, pas moins complexe que tout autre paradigme de programmation. Un système bien conçu OOP System gère et réduit la complexité, mais il est également très facile de concevoir un système beaucoup plus complexe que nécessaire et gêne tout.

Comme indiqué sur ladite de C++, OOP vous donne assez de corde pour vous accrocher.

1

Oop est une tentative d'une solution.

La meilleure façon de gérer la complexité est de créer des abstractions. Si je peux transformer mes données en collections utiles, avec des fonctions reconnaissables qui opèrent sur ces collections, je peux commencer à penser aux collections comme "choses" discrètes ". C'est la base des cours et des méthodes. À cet égard, correctement conçu OOP peut aider à gérer la complexité.

Quelque part le long du chemin, quelqu'un a décidé que nous pouvions utiliser OOP pour aider à résoudre le problème de la réutilisation de code. Je veux dire, pourquoi réinventer la roue? Si quelqu'un d'autre a apporté une grande partie des travaux visant à résoudre ce problème, expliquez-vous de ce qu'ils ont fait, ajoutez les modifications que votre projet particulier nécessite et voici! Vous avez créé une application puissante et sophistiquée avec relativement peu de travail de votre part. OO Les programmeurs peuvent être des programmeurs très productifs.

Le résultat final est que les programmeurs de modernisation OOfinissent par être "apprentis de sorcier", où ils attachent ensemble un tas de grandes bibliothèques lourdes avec quelques lignes de "colle" et obtiennent quelque chose qui fonctionne. Sorta. En quelque sorte. La plupart du temps. Existe-t-il des effets secondaires potentiels d'utiliser cette bibliothèque avec celle-là? Peut-être. Mais qui a le temps de creuser réellement le code contenu dans ces bibliothèques? Surtout lorsque les bibliothèques évoluent. Le résultat est que nous nous retrouvons avec des applications gonflées, où un programmeur avait besoin d'une poignée de classes et de méthodes de cette bibliothèque, mais l'application doit porter le poids de toutes les autres choses dont ils n'avaient pas besoin.

Le résultat final est que vous vous retrouvez avec beaucoup plus de complexité que nécessaire.

Un autre mécanisme pour faire face à la complexité que vous souhaitez séparer les fonctionnalités. Vous voulez toutes vos fonctions d'accès aux données au même endroit. Vous voulez toute votre fonctionnalité d'interface utilisateur au même endroit. Vous voulez tous vos contrôleurs au même endroit. Vous créez donc différentes classes qui gèrent différentes parties de la fonctionnalité. Jusqu'ici tout va bien. Et cette échelle, dans un degré; Vos développeurs qualifiés avec accès aux données peuvent écrire ces classes, votre interface utilisateur peut écrire les classes d'interface utilisateur, etc. Tout va bien et bien.

Jusqu'à ce que vous deviez maintenir quelque chose écrit par quelqu'un d'autre.

Oui, il est bon de savoir que toutes les fonctions d'accès aux données sont situées ici. Mais qu'est-ce qui les appelle?

Cette méthode appelle cette méthode sur cette classe. Mais lorsque je regarde la définition de la classe, il n'y a pas de méthode avec ce nom. Oh, c'est hérité de quelque chose d'autre une ou deux couches dans la chaîne d'héritage. Attendez une minute; Cette classe a mis en œuvre une interface? Combien de classes différentes implémentent cette interface? Et nous utilisons un système de gui-temps compliqué (je vous regarde, printemps) pour "filer ensemble" des cas de cours au moment de l'exécution? Où une classe qui implémente cette interface peut être utilisée?

Vous vous retrouvez avec beaucoup de petites méthodes discrètes qui font des choses précises. Mais celui-ci appelle celui-là, dans une autre classe. Qui appelle celui-ci, dans encore une autre classe. Qui appelle celui-là, dans une autre classe encore. Qui appelle celui-là, dans une classe supplémentaire. Qui retourne le résultat d'un type particulier. Sur lequel vous devez appeler une méthode pour faire une certaine chose. Qui retourne le résultat d'un autre type. Etc.

Il y a un terme pour cela: code spaghetti.

Vous vous retrouvez avec un système très complexe nécessaire pour composer le code. D'où des idées comme Visual Studio, Eclipse et NetBeans. Tous ont une courbe d'apprentissage importante. En effet, beaucoup d'entre eux sont capables d'encapsuler/d'agréger plusieurs outils, développés par différents groupes, chacun ayant leurs propres courbes d'apprentissage.

C'est la complexité de la gestion?

Le code de débogage est deux fois plus difficile que l'écrire. Bonne chance débogage de certaines de ces choses. Surtout s'il utilise plusieurs bibliothèques, "câblés ensemble" au moment de l'exécution en utilisant une sorte de système d'injection de dépendance.

En résumé: OOP donne ce qui ressemble à un outil prometteur pour aider à gérer la complexité. La réalité est que le code résultant a tendance à être horriblement bloqué (car vous ne pouvez pas extraire les pièces dont vous avez besoin de toutes ces bibliothèques liées) et vous avez besoin d'outils sophistiqués uniquement pour naviguer dans le code. Cela devient rapidement un cauchemar d'entretien.

IMHO, c'est une perte nette; Cela ajoute plus de complexité qu'il n'en élimine. Cela vous permet de faire des choses qui seraient extrêmement difficiles, peut-être même impossibles, sans cela. Mais tout grand projet évolue rapidement dans un gâchis non négligeable.

Si vous savez déjà comment cela fonctionne, vous pouvez vous en souvenir, vous pourriez avoir une chance de le maintenir.

N'oubliez pas d'appliquer la loi de Eagleson: tout code de votre choix, que vous n'avez pas examiné dans six mois, pourrait aussi bien être écrit par quelqu'un d'autre.

1
Meower68

Dans une certaine mesure...

Pourquoi? Parce qu'il facilite la modularité très logique. Au moins par rapport à la programmation procédurale où il est trop tentant de simplement écrire d'énormes piles de code spaghetti.

0
Bobby Tables

La programmation orientée vers l'objet semble nous aider à gérer la complexité est que cela nous oblige à écrire du code de manière spécifique au lieu d'une grande variété de façons. La programmation orientée opérationnelle est beaucoup plus intuitive, c'est pourquoi la programmation a commencé ainsi. L'orientation d'objet prend une formation et une pratique pour comprendre et utiliser efficacement, mais par contrainte de programmation dans un certain chemin, elle permet aux personnes formées de conserver efficacement le code qui a été écrit.

Ce n'est plus logique ou réel au monde que n'importe quelle autre méthode, c'est un moyen simplement de concentrer notre problème de résolution de lentilles similaires. Beaucoup de spécialités techniques utilisent le paradigme d'une méthodologie rigide non intuitive pour gérer la complexité de leurs tâches.

Une troisième méthode pour traiter la complexité serait une programmation fonctionnelle et il y aura probablement d'autres nouvelles méthodes à l'avenir.

0
user1842

je pense que c'est plus une solution à la main-d'œuvre, car, en tant que programmeur, vous êtes censé mettre des méthodes où vous avez les données, créant ainsi un modèle d'objet de votre application.

oui, c'est aussi une solution à la complexité en fournissant un modèle pour vous de "voir" votre code de manière naturelle, comme des objets ayant des propriétés et des actions possibles

0
Belun