La limite du paradigme de OOP dans un système vraiment complexe?

Les systèmes de toute complexité notable ne sont pas linéaires. Même si vous avez travaillé très fort pour faire un processus de système un système linéaire, vous comptez toujours sur des choses comme des disques, des connexions de mémoire et de réseau pouvant être squameuses, vous devez donc travailler autour de cela.

Je ne sais pas que quiconque pense que OOP est la réponse finale. C'est juste une façon de faire face à la complexité en essayant de garder divers problèmes confinés à la plus petite sphère possible afin que les dommages qu'ils effectuent lorsqu'ils explosent sont minimisés. Mon problème avec votre question est qu'il suppose que la perfection est possible. Si c'était le cas, je pourrais convenir de POOP n'est pas nécessaire. C'est pour moi jusqu'à ce que quelqu'un monte avec une meilleure façon pour moi de minimiser le nombre d'erreurs que je fais.

Ce que nous essayons de faire est de mettre un style OO sur un système relationnel. Dans C # Land, cela nous amène un système fortement dactylographié de sorte que tout de la fin à la fin peut être compilé et testé. La base de données a du mal à être testée, refactable, etc. OOP nous permet d'organiser notre application dans des couches et des arbres montrables qui ne permettent pas.

Eh bien, vous avez une question théorique.

Tout d'abord, permettez-moi d'être d'accord avec vous que OOP n'est pas une solution de résolution. C'est bon pour quelque chose, ce n'est pas bon pour les autres. Mais cela ne veut pas dire que cela n'échappe pas. Certains systèmes horriblement complexes et énormes ont été conçus en utilisant OOP.

Je pense que OOP est si populaire parce qu'il mérite d'être. Cela résout certains problèmes plutôt merveilleusement, il est facile de penser en termes d'objets parce que nous pouvons le faire sans ré-programmer nous-mêmes.

Donc, jusqu'à ce que nous puissions tous proposer une meilleure alternative qui fonctionne dans la vie pratique, je pense que OOP est une bonne idée et donc les bases de données relationnelles.

Il n'y a vraiment pas de limite à ce que OOP peut traiter - tout comme il n'y a pas de limite réelle à ce que c peut traiter ou assembler à ce sujet. Tous sont Turing-complet, ce qui est tout ce dont vous avez vraiment besoin.

OOP vous donne simplement un moyen de décomposition de niveau supérieur, tout comme C est un niveau supérieur à celui de l'assembleur.

L'article sur les systèmes d'entité ne dit pas que OO ne peut pas le faire - en fait, on dirait qu'elles utilisent OOP pour mettre en œuvre leurs entités, leurs composants, etc. dans n'importe quel domaine complexe, il y aura différentes façons de la rompre, et utiliser OOP, vous pouvez le casser au niveau objet / classe à un moment donné. Cela n'empêche pas d'avoir des cadres conceptuels de niveau supérieur qui sont utilisés pour concevoir le système OOP.

Le problème n'est pas l'approche orientée objet dans la plupart des situations, le problème est la performance et le développement réel du matériel sous-jacent.

Le développement du logiciel d'approche de la paradigme OO en nous fournissant une métaphore du monde réel, nous avons des concepts qui définissent les propriétés communes et attendues et les biens réels du monde. Est la façon dont les humains modélient les choses et sommes capables de résoudre la plupart des problèmes avec cela.

En théorie, vous pouvez définir tous les aspects d'un jeu, d'un système ou d'une utilisation de OO. En pratique, si vous le faites, votre programme se comportera simplement trop lentement, le paradigme est désespéré par des optimisations qui négocient la simplicité du modèle de la performance.

de cette façon, des bases de données relationnelles ne sont pas orientées objet, nous construisons donc une couche orientée objet entre notre code et la base de données ... En le faisant, vous avez perdu certaines des performances de la base de données et une partie de son expressivité car, de la Point de vue de OO Paradigm Une base de données relationnelle est une classe complète, est un objet très complexe qui fournit des informations.

De mon point de vue OO est une approche presque parfaite du sens théorique de la Parole, car elle mappe de près la façon dont nous, les humains, penser, mais cela ne convient pas aux ressources limitées du développement informatique. ... Nous prenons donc des raccourcis. A la place et la performance est beaucoup plus importante que l'organisation théorique ou la clarté afin que ces raccourcis deviennent des normes ou des pratiques habituelles.

C'est-à-dire que nous adaptons le modèle théorique à nos limitations actuelles. À l'époque de Cobol dans l'objet d'objet de la fin des années 70, il était tout simplement impossible ... cela impliquerait de nombreux aspects et trop peu de performances, nous avons donc utilisé une approche simplifiée, donc simplifiée que vous n'aviez pas d'objets ou de classe, vous avez eu des variables .. . Mais le concept était, à cette époque, la même chose. Groupes de variables décrites des concepts connexes, des propriétés qui seront aujourd'hui des pieds dans un objet. Séquences de contrôle basées sur une valeur variable dans laquelle il est utilisé pour remplacer les hiérarchies de classe et ainsi de suite.

Je pense que nous utilisons OOP depuis longtemps et que nous continuerons à l'utiliser pendant une longue période. Au fur et à mesure que les capacités matérielles améliorent, nous pourrons déplacer le modèle de sorte qu'il devienne plus adaptable. Si je décris parfaitement (presque) le concept d'un chat (qui implique beaucoup de décrire pour beaucoup de concepts impliqués), ce concept sera capable d'être réutilisé partout ... le problème ici n'est pas, comme je l'ai dit, avec le paradigme lui-même mais avec nos limitations pour la mettre en œuvre.

edit: Pour répondre à la question de savoir pourquoi utiliser pure OO. Chaque "science" veut avoir un modèle complet pour représenter des choses. Nous avons deux modèles physiques pour décrire la nature, l'un au niveau microscopique et un pour le macroscopique, et nous voulons en avoir une seule parce que cela simplifie les choses qu'il nous fournit un meilleur moyen de prouver, de tester et de développer des choses. Avec OO le même processus s'applique. Vous ne pouvez pas tester analytiquement et prouver un système si le système ne suit pas un ensemble de règles précis. Si vous évoluez entre paradigmes dans un programme, votre programme ne peut pas être correctement analysé, il doit être malisé dans chacun, analysé puis analysé à nouveau pour voir que les interactions sont correctes. Il rend beaucoup plus difficile à comprendre un système car, en fait, vous avez deux ou trois systèmes qui interagissent de différentes manières.