Est orienté objet Programmation d'une solution à la complexité? [fermé]
-
22-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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 Pourquoi des experts ici!
La solution
Il n'y a pas de solution à la complexité.
Dans « Le Mythical Man-Month », Fred Brooks traite de la différence entre la complexité accidentelle et essentielle dans la programmation. complexité accidentelle est causée par nos outils et méthodes, comme ayant le code supplémentaire écrire et tester dans une langue parce que 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 moi il y a vingt-cinq ans, parce que j'ai de meilleures langues et des outils.
complexité essentielle vient du fait qui est intrinsèquement compliqué ce que nous essayons de faire avec la programmation, et qu'il existe une complexité irréductible. « Essential », dans ce contexte, des moyens « relatifs à 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 solution miracle, que le logiciel d'écriture continuera d'être difficile.
Je recommande vivement de lire son livre: en particulier, je recommande l'édition anniversaire d'argent, avec un essai supplémentaire « No Silver Bullet ». En cela, il passe en revue les solutions proposées à la complexité et considère leur impact. (Ce qu'il trouve le plus efficace est un logiciel film rétractable - écrire quelque chose complexe une fois, et vendre des milliers ou des millions d'exemplaires.)
Maintenant, aide la programmation orientée objet, quand bien fait, en créant des abstractions et se cachant la complexité. Un objet d'une classe a un certain comportement défini que nous pouvons raisonner à partir, sans se soucier de la complexité de la mise en œuvre. les classes correctement écrites ont une faible couplage entre eux, et de diviser pour mieux régner est une excellente façon de faire face à la complexité si vous pouvez vous en sortir avec elle. Ils ont également une forte cohésion, en ce sens qu'ils sont un ensemble de fonctions et les données qui se rapportent de très près les uns des autres.
Autres conseils
Je vous attends vous obtiendrez de meilleures réponses peu, mais voici un simple:
* POO aide à la complexité par le logiciel de modélisation d'une manière plus proche du modèle de façon que nous tout le reste dans le monde. Il est juste généralement plus facile à l'image d'un objet balle en interaction avec un objet mur que d'imaginer une série de routines et des 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 complexité 'résoudre'
Je pense que la définition dominante actuelle de la POO n'est pas une bonne solution pour gérer la complexité.
Si vous revenez à ses racines, je crois Alan Kay a été influencé par « Lisp » beaucoup.
Parce que Lisp n'a pas été corrompu par l'adoption grand public, il a probablement réussi à conserver ses valeurs fondamentales. Je pense donc regarder comment Lisp ce problème de tacles de la complexité pourrait nous donne un aperçu, et nous pouvons l'utiliser comme base pour sorte de juge quelle est l'utilité POO à faire face à la complexité.
Si vous regardez à la fin de la "Conférence 3a: Henderson Escher Exemple" de SICP , Hal Abelson propose que la complexité est gérée pas en brisant la tâche en sous-tâches plus petites, mais en créant des couches d'abstraction. Au plus haut niveau, vous exprimez la solution au problème complexe en termes de la solution au niveau d'abstraction inférieur.
Je pense que POO a été initialement conçu comme un mécanisme pour créer ces couches d'abstractions.
Malheureusement, de nos jours, est OOP (ab) utilisé pour écrire le code spaghetti / structures.
Je compenserai un exemple:. Un jeu multi-joueurs FPS
Au plus haut niveau, le jeu fonctionne en ayant un groupe de joueurs en cours d'exécution autour d'une carte et à se tirer dessus avec des armes.
Au niveau inférieur, 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, on peut parler de la façon dont les objets interagissent physiquement (mouvement, collisions, etc.).
Et ainsi de suite et ainsi de suite.
Ce que cela signifie, (et je suis un peu citer SICP ..), est que chaque couche, nous résolvons non seulement un problème spécifique particulier, mais une classe de problèmes de ce genre de chute dans le quartier de la problème que nous essayons de résoudre. Donc, s'il y a un petit changement dans la description du problème, il faudrait probablement qu'un petit changement dans la solution.
Alors, la façon sage d'utiliser POO est de créer des couches d'abstractions, à chaque niveau d'abstraction, vous résoudre le problème à la main en utilisant les « objets » du niveau qui est directement au-dessous.
Voici le bit que je citais la conférence: http://www.youtube.com/watch?v=CYtrfncMqHQ
Comme d'habitude je suis en désaccord avec tout le monde. Loin de vous donner des outils pour gérer la complexité, POO crée une énorme quantité de complexité, car il est un paradigme inadéquat et mathématiquement faux. Il brouille les programmeurs sans fin, d'essayer des choses modèles avec POO qui ne peuvent être modelés avec POO.
Selon moi, le travail séminal ici est l'objet de Meyer Oriented Software Construction. Il détaille un ensemble d'exigences, y compris une matière I comme cruciale: l'Open fermé Principe. Cela dit qu'une chose doit être ouverte pour l'extension, mais fermée pour une utilisation, en même temps.
Meyer procède à Derive Orientation objet de ces exigences, telles qu'elles résultent de Eiffel. Encapsulation fournit la fermeture, l'héritage-ness ouvert, et dit « chose » est la classe.
Je considère ce travail comme une bonne science parce que Meyer était manifestement mal, et il est possible en raison de la qualité de son travail, au point d'épingle l'erreur et le fixer.
L'erreur fait la classe ou le type, l'unité de modularité. C'est faux, et donc démontrable. Même Meyer a reconnu le problème (appelé le problème de covariance), que la POO ne peut pas gérer les relations d'arité supérieur à un (qui est, POO fonctionne très bien pour les propriétés, mais échoue sur les relations binaires). En Eiffel, ce problème a donné lieu à un mal fondée dans le système de type!
La solution est tout à fait claire. L'unité de modularité doit être plus grand qu'un seul type. Il doit être composé de plusieurs types, et les méthodes les concernant.
Il est guère surprenant que ce modèle d'abstraction est soutenu par la théorie mathématique de l'abstraction, à savoir la théorie des catégories. Types sont des objets d'une catégorie et méthodes (fonctions) sont des flèches
Avec ce modèle, les représentations de plusieurs types sont connus pour un ensemble de fonctions. La représentation est cachée au public, donc c'est encapulsation, mais nous utilisons des modules, non classes.
La norme métalangage (SML) et Ocaml sont basées directement sur ce modèle. OCaml a aussi des cours et POO: ce n'est pas inutile parce que POO vous donne expédiez sur les propriétés, alias la liaison dynamique. Cependant, des problèmes mondiaux les plus réels impliquent des relations et il est à peine surprenant les classes ne sont pas utilisés beaucoup en Ocaml.
Il est peu surprenant héritage est à peine utilisé du tout dans la bibliothèque de modèles standard C ++.
Le simple fait est, POO ne vous donne pas les bons outils à la complexité de la poignée, il n'a même pas vous donner les outils pour gérer des problèmes très simples, au lieu qu'il a induits en erreur et confondu deux générations de programmeurs. Loin d'aider, OOP est le plus mauvais et le mauvais qui est arrivé à la programmation en C depuis, Fortran et Cobol ont commencé à se fatiguer.
La programmation orientée objet a des racines qui remontent aux années 1960. Comme le matériel et les logiciels sont devenus, de gestion de plus en plus complexe devient souvent une préoccupation. Les chercheurs ont étudié les moyens de maintenir la qualité des logiciels et développé la programmation orientée objet en partie pour répondre aux problèmes communs en mettant l'accent fortement unités discrètes, réutilisables de la logique de programmation.
Ainsi, un programme orienté objet peut être considéré comme une collection d'objets qui interagissent, par opposition au modèle classique, dans lequel un programme est considéré comme une liste de tâches (sous-programmes) à effectuer. En POO, chaque objet est capable de recevoir des messages, des données de traitement, et l'envoi de messages à d'autres objets. Chaque objet peut être considéré comme une « machine » indépendante avec un rôle distinct ou la responsabilité. Les actions (ou "méthodes") sur ces objets sont étroitement associés à 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 tels que le polymorphisme, l'héritage, le passage de messages, le découplage et l'encapsulation, fournir un cadre logique et conceptuel par lequel la complexité des grands programmes peuvent être gérés de manière très efficace.
Il existe plusieurs types de complexité pour le développement de logiciels. Au niveau de la programmation, POO cherche à la complexité d'adresse en utilisant des objets et des classes pour modéliser le domaine du problème. A dit la résolution de problèmes gourou bien connu est juste représente le problème afin que la solution est la représentation elle-même. Par conséquent, par l'abstraction en utilisant des classes, l'encapsulation en utilisant des modificateurs d'accès et les méthodes, l'héritage pour spécifier la relation et la réutilisation, la composition en établir des relations et de la collaboration entre les classes, polymorphisme comme un moyen de simplifier la détermination des comportements différents dans des objets similaires, la complexité peut être géré.
Il y a aussi d'autres façons de gérer la complexité des logiciels, par exemple, la logique (Prolog) et la programmation fonctionnelle (Haskell).
A un niveau supérieur à la programmation, nous avons besoin de concevoir des modèles et principes pour guider la POO. D'où la POO gère la complexité à un faible (codage) niveau alors que ces méthodes telles que les modèles de conception et les principes qui guident la conception de la solution à un niveau supérieur (système et application) et faire du développement logiciel et la manipulation plus facile à gérer la complexité.
Pour répondre à votre question, oui, OOP est juste une solution pour le traitement de la complexité parmi beaucoup d'autres solutions. Il est une solution à un niveau bas. Nous avons besoin de concevoir des modèles et principes pour guider OOP dans un niveau supérieur.
La programmation orientée objet gère complexité essentielle et en option, mais ne réduit pas non plus.
Je préfère la définition donnée par Eric Steven Raymond L'art de la programmation Unix , parce qu'il délimite entre la complexité essentielle, en option, et accidentelle. http://www.faqs.org/docs/artu/ch13s01.html#id2964646
POO ne fait rien pour la complexité essentielle ou facultative, ils sont fonction des exigences du programme. Il peut avoir un effet sur la complexité accidentelle dans la mesure où vous pouvez créer un design plus élégant parfois avec POO. Parfois, cependant, la conception est pire lorsque vous utilisez POO.
Les problèmes complexes ne peuvent pas être rendus plus simples grâce à la technologie, ils ne peuvent être géré grâce à la technologie.
POO est une technologie, un concept, et une façon d'aborder un problème.
POO vous donne les outils nécessaires pour appliquer une conception qui peut le rendre plus facile à gérer la complexité, mais vous pouvez tout aussi bien avoir une mauvaise conception qui augmente votre complexité. En d'autres termes, si non utilisé correctement, vous pouvez avoir la complexité induite par la technologie dans vos problèmes.
Gardez à l'esprit qu'il ya beaucoup d'autres aspects qui dictera la réussite de votre projet sera (à savoir le style de gestion de projet, la définition du problème, la gestion du changement, etc ...). La technologie utilisée est pertinente que dans combien va vous aider à Gérer le problème.
En fin de compte, programmation orientée objet ne peut pas être solution à la complexité; il est juste un outil pour le gérer. (si elle est utilisée correctement)
Orientation de l'objet (comme classiquement utilisé) est un outil utile dans de nombreuses circonstances, mais il est pas une solution suffisante à la complexité.
En particulier, il ajoute souvent beaucoup de " complexité accessoire ". Les exemples sont la complexité entourant l'héritage de mise en œuvre, la nécessité de fournir un bon nombre de « fonctionnalité standard » suach comme égaux () et hashCode (), etc. Une belle présentation par Stuart Halloway sur ce sujet: « La simplicité est pas facile "
Objets dans la plupart des langues ont également tendance à résumer beaucoup d'état mutable - qui, dans un monde de plus en plus en même temps commence à ressembler à une décision de mauvaise conception. Encore une fois un intéressant vidéo par les regards de Rich Hickey à la distinction entre l'objet l'identité et de l'état, et comment il pourrait être une erreur de confondre les deux.
programmation orientée objet est une façon de représenter un problème, rien de plus, rien de moins. Il est, en soi, pas moins complexe que tout autre paradigme de programmation. Système bien conçu POO et réduit la complexité gère, mais il est aussi très facile de concevoir un système qui est beaucoup plus complexe que nécessaire et obtient de la manière de tout.
Comme dit souvent de C ++, POO vous donne assez de corde pour se pendre.
Je pense que YES , juste parce qu'il vous permet de la complexité de couper en petits « blocs de construction » auto contenant que cacher les détails, puis les utiliser pour créer les fonctionnalités dont vous avez besoin, étape par étape, couche par couche.
Diviser pour mieux régner.
POO est une tentative de solution.
La meilleure façon de gérer la complexité est de créer des abstractions. Si je peux mettre mes données dans des collections utiles, avec des fonctions reconnaissables qui opèrent sur ces collections, je peux commencer à penser sur les collections comme discrètes « les choses. » C'est la base pour les classes et méthodes. À cet égard, POO bien conçu peut aider à gérer la complexité.
Quelque part le long du chemin, quelqu'un a décidé que nous pourrions 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 fait beaucoup de travail en vue de résoudre ce problème, l'effet de levier ce qu'ils ont fait, ajoutez les réglages que votre, projet particulier et le tour est joué EXIGE! Vous avez créé une application puissante et sophistiquée avec relativement peu de travail de votre part. Les programmeurs peuvent être OO programmeurs très productifs.
Le résultat final est que les programmeurs OO modernes finissent par être « apprentis sorciers », où ils lient ensemble un tas de grandes bibliothèques, difficiles à manier avec quelques lignes de « colle » et obtenir quelque chose qui fonctionne. Sorta. Kinda. Le plus souvent. Y at-il des effets secondaires potentiels de l'utilisation de cette bibliothèque que l'on? Peut être. Mais qui a le temps de vraiment creuser dans le code contenu dans ces bibliothèques? Surtout quand les bibliothèques évoluent. Le résultat est que nous nous retrouvons avec des applications pléthorique, où un programmeur avait besoin d'une poignée de classes et méthodes de cette bibliothèque, mais l'application doit supporter le poids de tous les trucs AUTRES qu'ils ne ont pas besoin.
Le résultat final est que vous vous retrouvez avec beaucoup plus de complexité que vous avez besoin.
Un autre mécanisme pour faire face à la complexité que vous voulez séparer la fonctionnalité. Vous voulez que tous vos fonctions d'accès aux données en un seul endroit. Vous voulez toutes les fonctionnalités de votre interface utilisateur en un seul endroit. Vous voulez que tous vos contrôleurs en un seul endroit. Donc, vous créez des classes différentes qui gèrent les différentes parties de la fonctionnalité. Jusqu'ici tout va bien. Et ce pèse-personne, à un degré; vos développeurs qui sont qualifiés avec accès aux données peuvent écrire ces classes, votre peuple d'interface utilisateur peuvent écrire les classes d'interface utilisateur, etc. Tout est bien et bon.
Jusqu'à ce que vous devez maintenir quelque chose d'écrit par quelqu'un d'autre.
Oui, il est bon de savoir que toutes les fonctions d'accès aux données se trouvent ici. Mais ce qui les appelle?
Cette méthode appelle cette méthode sur cette classe. Mais quand je regarde la définition de la classe, il n'y a pas de méthode avec ce nom. Oh, qui est hérité de quelque chose d'autre une ou deux couches dans la chaîne d'héritage. Attends une minute; cette classe a mis en œuvre une interface? Combien de classes différents outils de cette interface? Et nous utilisons un système d'exécution compliqué (je vous regarde, Spring) à « fils » ensemble des instances de classes à exécution? Si 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 que l'on appelle, dans une autre classe. Quels sont les appels que l'on, dans une autre classe. Quels sont les appels que l'on, dans encore une autre classe. Quels sont les appels que l'un, dans une classe supplémentaire. Ce qui renvoie un résultat d'un type particulier. Sur lequel vous devez appeler une méthode pour faire une certaine chose. Ce qui renvoie un résultat d'un autre type. Etc.
Il y a un terme pour cela:. Code spaghettis
Vous vous retrouvez avec un système très complexe nécessaire juste pour composer le code. D'où IDEs comme Visual Studio, Eclipse et NetBeans. Tous qui ont une courbe d'apprentissage importante. En effet, beaucoup d'entre eux sont en mesure de encapsulent / agrégats multiples outils, mis au point par différents groupes, dont chacun ont leurs propres courbes d'apprentissage.
est la gestion de la complexité?
Debogage est deux fois plus difficile que l'écrire. Bonne chance débogage certains de ce genre de choses. Surtout s'il utilise plusieurs bibliothèques, « câblés ensemble » à l'exécution en utilisant une sorte de dépendance-InjeSystème de ction.
En résumé: POO fournit ce qui ressemble à un outil prometteur pour aider à gérer la complexité. La réalité est le code qui en résulte a tendance à être horriblement gonflé (parce que vous ne pouvez pas extraire seulement les pièces dont vous avez besoin de toutes ces bibliothèques liées) et vous avez besoin d'outils sophistiqués juste pour naviguer dans le code. Il devient rapidement un cauchemar d'entretien.
à mon humble avis, il est une perte nette; il ajoute plus de complexité qu'il élimine. Il ne vous permet de faire des choses qui serait extrêmement difficile, voire impossible, sans elle. Mais tout grand projet évolue rapidement dans un désordre difficile à maintenir.
Si vous savez déjà comment cela fonctionne, et vous pouvez rappeler que, vous pourriez avoir une chance à maintenir.
Souvenez-vous d'appliquer la loi de Eagleson. Tout code de votre, que vous ne l'avez pas regardé en six mois, pourrait aussi bien être écrit par quelqu'un d'autre
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 tas de code spaghetti.
La raison la programmation orientée objet semble nous aider à gérer la complexité est parce qu'il nous oblige à écrire du code d'une manière spécifique au lieu d'une grande variété de façons. programmation orientée tâche est beaucoup plus intuitive, ce qui explique pourquoi la programmation a commencé de cette façon. Orientation de l'objet prend la formation et la pratique pour comprendre et utiliser efficacement, mais par programmation contraignante dans une certaine voie, il permet à ceux formés pour maintenir efficacement le code qui a été écrit.
Il est plus logique ou dans le monde réel que toute autre méthode, il est juste un moyen de se concentrer notre résolution de problèmes à travers des 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 à la complexité de la poignée serait la programmation fonctionnelle, et il y aura probablement d'autres nouvelles méthodes à l'avenir également.
Je pense qu'il est plus d'une solution à maintenabilité, parce que, 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, il est aussi une solution à la complexité en fournissant un modèle pour vous « voir » votre code d'une manière naturelle, comme des objets qui ont des propriétés et des actions possibles
