Challengers importants de la POO

Question

D'après ce que j'ai compris, la POO est le paradigme le plus couramment utilisé pour les projets à grande échelle.Je sais aussi que certains sous-ensembles plus petits de grands systèmes utilisent d'autres paradigmes (par ex.SQL, qui est déclaratif), et je me rends également compte qu'à des niveaux de calcul inférieurs, la POO n'est pas vraiment réalisable.Mais il me semble que les éléments de solutions de niveau supérieur sont généralement assemblés de manière POO.

Existe-t-il des scénarios dans lesquels un paradigme véritablement non-POO est en réalité un mieux choix pour une solution à grande échelle ?Ou est-ce du jamais vu de nos jours ?

Je me pose la question depuis que j'ai commencé à étudier l'informatique ;il est facile d'avoir le sentiment que la POO est un nirvana de programmation qui ne sera jamais surpassé.

Answer 1

A mon avis, la POO raison est utilisée si largement pas tant que c'est le bon outil pour le travail. Je pense qu'il est plus qu'une solution peut être décrite au client de manière à ce qu'ils comprennent.

Une voiture est un véhicule qui a un moteur. C'est toute la programmation et le monde réel en un!

Il est difficile de comprendre tout ce qui peut adapter le monde de la programmation et réelle tout à fait avec tant d'élégance.

Answer 2

Linux est un projet à grande échelle qui est très bien pas POO. Et ce ne serait pas avoir beaucoup à gagner non plus.

Je pense que POO a un bon anneau, car elle s'est associée aux bonnes pratiques de programmation comme l'encapsulation, dissimulation de données, la réutilisation de code, modularité et.c. Mais ces vertus sont pas uniques à POO.

Answer 3

Vous pouvez jeter un oeil à Erlang, écrit par Joe Armstrong.

Wikipedia:

  

"Erlang est un usage général   langage de programmation simultanée et   système d'exécution. Le sous-ensemble séquentiel   de Erlang est un langage fonctionnel,   avec une évaluation stricte, unique   affectation et typage dynamique. "

Joe Armstrong:

  

« Parce que le problème   langages orientés objet est qu'ils ont   a obtenu tout cet environnement implicite   ils portent avec eux. Toi   voulait une banane, mais ce que tu as été un   gorille tenant la banane et la   jungle entier. »

Answer 4

La promesse de la POO est la réutilisation du code et un entretien plus facile. Je ne sais pas le faire livrer. Je vois des choses comme dot net comme étant la même que les bibliothèques C que nous avons utilisées pour obtenir fro différents fournisseurs. Vous pouvez appeler la réutilisation de code si vous voulez. En ce qui concerne le code mauvais entretien est mauvais code. POO n'a pas aidé.

Answer 5

Je suis le plus grand fan de la POO, et je pratique POO tous les jours. Il est le moyen le plus naturel d'écrire du code, car il ressemble à la vraie vie.

Bien, je me rends compte que la virtualisation de la POO pourrait causer des problèmes de performance. Bien sûr, cela dépend de votre conception, la langue et la plate-forme que vous avez choisi (systèmes d'écriture dans les langues à base de collecte de déchets tels que Java ou C # peut de moins bons résultats que les systèmes qui ont été écrits en C ++ par exemple).

Je suppose que dans les systèmes en temps réel, la programmation procédurale peut être plus approprié.

Answer 6

Notez que tous les projets qui prétendent être OOP sont OOP fait. Parfois, la majorité du code est d'ordre procédural, ou le modèle de données est anémique , et ainsi de suite. ..

Answer 7

Zyx, vous avez écrit: "La plupart des systèmes utilisent des bases de données relationnelles ..."

Je crains qu'il n'y ait pas une telle chose. Le modèle relationnel sera 40 ans l'année prochaine et a encore jamais été mis en œuvre. Je pense que vous voulez dire, « bases de données SQL. » Vous devriez lire quoi que ce soit par Fabian Pascal pour comprendre la différence entre un SGBDR et un DBMS SQL.

« ... le modèle relationnel est généralement choisi en raison de sa popularité, »

Certes, il est populaire.

"... la disponibilité d'outils,"

Hélas, sans l'outil principal nécessaire:. Une mise en œuvre du modèle relationnel

"soutien",

Eh oui, le modèle relationnel a bien le soutien, je suis sûr, mais il est tout à fait non pris en charge par une mise en œuvre DBMS.

« et le fait que le modèle relationnel est en fait un concept mathématique, »

Oui, il est un concept mathématique, mais pas mis en œuvre, il est en grande partie limité aux tours d'ivoire. La théorie des cordes est aussi un concept mathématique, mais je ne mettre en œuvre un système avec.

En fait, en dépit de son être un concept methematical, il est certainement pas une science (comme dans la science informatique) parce qu'il n'a pas la première exigence de toute science: qu'il est falsifiable: il n'y a pas la mise en œuvre d'un SGBDR contre lequel nous peut vérifier ses allégations.

Il est l'huile pure de serpent.

"... contrairement à la POO."

Et contrairement à la POO, le modèle relationnel n'a jamais été mis en œuvre.

Acheter un livre sur SQL et obtenir productive.

Laissez le modèle relationnel pour les théoriciens non productifs.

Answer 8

Voir cette et cette . Apparemment, vous pouvez utiliser C # avec cinq différents paradigmes de programmation, C ++ avec trois, etc.

construction de logiciel n'est pas apparenté à la physique fondamentale. Physique visent à décrire la réalité en utilisant des paradigmes qui peuvent être contestées par de nouvelles données expérimentales et / ou théories. La physique est une science qui recherche une « vérité », d'une manière que la construction du logiciel ne fonctionne pas.

construction de logiciels est une entreprise . Vous devez être productif , à savoir pour atteindre certains objectifs pour lesquels quelqu'un verser de l'argent. Paradigmes sont utilisés parce qu'ils sont utiles à produits logiciels efficacement . Vous n'avez pas besoin tout le monde d'accord. Si je fais POO et il fonctionne bien pour moi, je ne me soucie pas si un « nouveau » paradigme serait potentiellement 20% plus utile pour moi si j'avais le temps et d'argent pour apprendre et plus tard repenser toute la structure du logiciel I » m travail et un nouveau design à partir de zéro.

En outre, que vous pourriez utiliser un autre paradigme et je serai encore heureux, de la même manière que je peux faire de l'argent en cours d'exécution d'un restaurant de cuisine japonaise, et vous pouvez faire de l'argent avec un restaurant cuisine mexicaine à côté. Je ne ai pas besoin de discuter avec vous si la nourriture japonaise est mieux que la cuisine mexicaine.

Answer 9

Je doute POO va disparaître de sitôt, il se glisse tout simplement nos problèmes et modèles mentaux beaucoup trop bien.

Ce que nous commençons à voir si des approches est multi-paradigme, avec des idées déclaratives et fonctionnels étant intégrés à la conception orientée objet. La plupart des langues JVM plus récentes sont un bon exemple (JavaFX, Scala, Clojure, etc.), ainsi que LINQ et F # sur la plate-forme .NET.

Il est important de noter que je ne parle pas de remplacer OO ici, mais de le compléter.

• JavaFX a montré qu'un déclaratif solution va au-delà SQL et XSLT, et peut également être utilisé pour la liaison propriétés et événements entre visuel composants dans une interface utilisateur graphique

• Pour tolérance aux pannes et très systèmes concurrents, fonctionnel la programmation est un très bon ajustement, comme le montre le Ericsson AXD301 (programmé en utilisant Erlang)

Alors ... que devient plus important concurrency et FP devient plus populaire, je pense que les langues ne supportant pas ce paradigme en souffrira. Cela inclut de nombreux qui sont actuellement populaires tels que C ++, Java et Ruby, bien que JavaScript doit faire face très bien.

Answer 10

Utilisation POO rend le code plus facile à gérer (comme dans modify / mise à jour / ajouter de nouvelles fonctionnalités) et à comprendre. Cela est particulièrement vrai avec de plus grands projets. Parce que les modules / objets encapsulent leurs données et leurs opérations sur ces données, il est plus facile de comprendre la fonctionnalité et la grande image.

L'avantage de la POO est qu'il est plus facile de discuter (avec d'autres développeurs / gestion / client) un LogManager ou OrderManager, dont chacun englobe des fonctionnalités spécifiques, puis décrivant « un groupe de méthodes qui déversent les données dans le fichier » et « les méthodes qui gardent la trace des détails de la commande ».

Je suppose que la POO est utile surtout avec de grands projets, mais il y a toujours de nouveaux concepts de rotation de façon à ce continuer à affût de nouvelles choses à l'avenir, d'évaluer et de garder ce qui est utile.

Answer 11

Les gens aiment penser à différentes choses comme des « objets » et les classer, donc aucun doute que la POO est si populaire. Cependant, il y a des zones où la POO n'a pas gagné une plus grande popularité. La plupart des systèmes utilisent des bases de données relationnelles plutôt que l'objectif. Même si les seconds détiennent des records notables et sont meilleurs pour certains types de tâches, le modèle relationnel est unsually choisi en raison de sa popularité, la disponibilité des outils, le soutien et le fait que le modèle relationnel est en fait un concept mathématique, contrairement à POO.

Un autre domaine où je ne l'ai jamais vu OOP est le processus de construction de logiciels. Toute la configuration et faire des scripts sont d'ordre procédural, en partie à cause du manque de soutien à la POO dans les langues shell, en partie parce que la POO est trop complexe pour de telles tâches.

Answer 12

Opinion légèrement controversée de ma part, mais je ne trouve pas que la POO, du moins celle qui est couramment appliquée aujourd'hui, soit que utile pour produire le logiciel à plus grande échelle dans mon domaine particulier (VFX, qui est quelque peu similaire dans l'organisation de la scène et l'état de l'application à ceux des jeux).Je le trouve très utile à une échelle moyenne à petite.Je dois être un peu prudent ici puisque j'ai invité des foules dans le passé, mais je dois préciser que cela relève de mon expérience étroite dans mon type particulier de domaine.

La difficulté que j'ai souvent rencontrée est que si vous avez tous ces petits objets concrets encapsulant des données, ils veulent désormais tous communiquer entre eux.Les interactions entre eux peuvent devenir extrêmement complexes, comme ceci (sauf beaucoup, beaucoup plus complexe dans une application réelle couvrant des milliers d'objets) :

Et ce n'est pas tant un graphe de dépendance directement lié au couplage qu'un "graphe d'interaction".Il pourrait y avoir des abstractions pour découpler ces objets concrets les uns des autres. Foo pourrait ne pas parler à Bar directement.Il pourrait plutôt lui parler à travers IBar ou quelque chose de ce genre.Ce graphique serait toujours connecté Foo à Bar puisque, bien que découplés, ils se parlent toujours.

Et toute cette communication entre objets de petite et moyenne taille qui constituent leur propre petit écosystème, si elle est appliquée à l'échelle entière d'une grande base de code dans mon domaine, peut devenir extrêmement difficile à maintenir.Et cela devient très difficile à maintenir car il est difficile de raisonner sur ce qui se passe avec toutes ces interactions entre objets en ce qui concerne des choses comme les effets secondaires.

Au lieu de cela, ce que j'ai trouvé utile, c'est d'organiser la base de code globale en sous-systèmes volumineux et complètement indépendants qui accèdent à une « base de données » centrale.Chaque sous-système entre et sort ensuite des données.Certains autres sous-systèmes peuvent accéder aux mêmes données, mais sans qu'aucun système ne communique directement entre eux.

...ou ca:

...et chaque système individuel ne tente plus d’encapsuler l’état.Il ne cherche pas à devenir son propre écosystème.Au lieu de cela, il lit et écrit des données dans la base de données centrale.

Bien entendu, lors de l’implémentation de chaque sous-système, ils peuvent utiliser un certain nombre d’objets pour faciliter leur implémentation.Et c'est là que je trouve la POO très utile, c'est dans la mise en œuvre de ces sous-systèmes.Mais chacun de ces sous-systèmes constitue un projet à échelle relativement moyenne à petite, pas trop grand, et c'est à cette échelle moyenne à petite que je trouve la POO très utile.

"Programmation de chaînes d'assemblage" avec un minimum de connaissances

Cela permet à chaque sous-système de se concentrer uniquement sur son travail sans presque aucune connaissance de ce qui se passe dans le monde extérieur.Un développeur se concentrant sur la physique peut simplement s'asseoir avec le sous-système physique et savoir peu de choses sur le fonctionnement du logiciel, sauf qu'il existe une base de données centrale à partir de laquelle il peut récupérer des éléments tels que des composants de mouvement (juste des données) et les transformer en appliquant la physique à ces données.Et cela rend son travail très simple et lui permet de faire ce qu'il fait de mieux avec un minimum de connaissances sur le fonctionnement de tout le reste.Données centrales d'entrée et données centrales de sortie :c'est tout ce que chaque sous-système doit faire correctement pour que tout le reste fonctionne.C'est la chose la plus proche que j'ai trouvée dans mon domaine de la "programmation en ligne d'assemblage" où chaque développeur peut faire son travail avec un minimum de connaissances sur le fonctionnement global du système.

Les tests restent également assez simples en raison de la portée étroite de chaque sous-système.Nous ne nous moquons plus d'objets concrets avec l'injection de dépendances, mais générons une quantité minimale de données pertinentes pour un système particulier et testons si le système particulier fournit la sortie correcte pour une entrée donnée.Avec si peu de systèmes à tester (des dizaines seulement peuvent constituer un logiciel complexe), cela réduit également considérablement le nombre de tests requis.

Briser l'encapsulation

Le système se transforme alors en un pipeline plutôt plat transformant l'état central de l'application en sous-systèmes indépendants qui ignorent pratiquement l'existence des autres.On peut parfois transmettre un événement central à la base de données qu'un autre système traite, mais cet autre système ignore toujours d'où vient cet événement.J'ai trouvé que c'est la clé pour aborder la complexité au moins dans mon domaine, et cela passe efficacement par un système entité-composant.

Pourtant, cela ressemble plus à une programmation procédurale ou fonctionnelle à grande échelle pour découpler tous ces sous-systèmes et les laisser fonctionner avec une connaissance minimale du monde extérieur puisque nous brisons l'encapsulation pour y parvenir et éviter d'exiger que les systèmes communiquent entre eux. autre.Lorsque vous effectuez un zoom avant, vous constaterez peut-être que votre part d'objets est utilisée pour implémenter l'un de ces sous-systèmes, mais à l'échelle la plus large, les systèmes ressemblent à autre chose que la POO.

Données mondiales

Je dois admettre que j'étais très hésitant à l'idée d'appliquer ECS au début à une conception architecturale dans mon domaine car, premièrement, cela n'avait jamais été fait à ma connaissance chez des concurrents commerciaux populaires (3DS Max, SoftImage, etc.), et deuxièmement , cela ressemble à tout un tas de données accessibles à l’échelle mondiale.

J'ai cependant constaté que ce n'était pas un gros problème.Nous pouvons encore maintenir les invariants de manière très efficace, peut-être même mieux qu’avant.La raison est due à la manière dont l'ECS organise tout en systèmes et composants.Vous pouvez être assuré qu'un système audio n'essaiera pas de muter un composant de mouvement, par exemple, même dans les situations les plus piratées.Même avec une équipe mal coordonnée, il est très improbable que l'ECS se dégrade en quelque chose où vous ne pouvez plus raisonner sur quels systèmes accèdent à quel composant, car c'est plutôt évident sur le papier et il n'y a pratiquement aucune raison pour qu'un certain système accède à tel ou tel composant. un composant inapproprié.

Au contraire, cela a souvent éliminé bon nombre des anciennes tentations de piratage avec des données largement ouvertes, car beaucoup de choses piratées effectuées dans notre ancienne base de code avec une coordination lâche et un temps de crise ont été faites dans des tentatives hâtives de rayons X abstractions et d'essayer de accéder aux internes des écosystèmes d’objets.Les abstractions ont commencé à fuir parce que les gens, pressés, essayaient simplement d'obtenir et de faire des choses avec les données auxquelles ils voulaient accéder.Ils sautaient essentiellement à travers des obstacles en essayant simplement d'accéder aux données, ce qui conduisait à une dégradation rapide des conceptions d'interface.

Il y a quelque chose qui ressemble vaguement à de l'encapsulation, justement en raison de la manière dont le système est organisé puisqu'il n'y a souvent qu'un seul système modifiant un type particulier de composants (deux dans certains cas exceptionnels).Mais ils ne possèdent pas ces données, ils ne fournissent pas de fonctions pour récupérer ces données.Les systèmes ne se parlent pas.Ils fonctionnent tous via la base de données centrale ECS (qui est la seule dépendance qui doit être injectée dans tous ces systèmes).

Flexibilité et extensibilité

Ceci est déjà largement discuté dans les ressources externes sur les systèmes d'entité-composants, mais ils sont extrêmement flexibles pour s'adapter à des idées de conception radicalement nouvelles avec le recul, même les concept comme une suggestion pour une créature qui est un mammifère, un insecte et une plante qui plante qui Les germes de feuilles sous la lumière du soleil à la fois.

L’une des raisons est qu’il n’y a aucune abstraction centrale à briser.Vous introduisez de nouveaux composants si vous avez besoin de plus de données pour cela ou créez simplement une entité qui regroupe les composants requis pour une plante, un mammifère et un insecte.Les systèmes conçus pour traiter les composants d'insectes, de mammifères et de plantes les récupèrent ensuite automatiquement et vous pouvez obtenir le comportement souhaité sans rien changer, à part l'ajout d'une ligne de code pour instancier une entité avec une nouvelle combinaison de composants.Lorsque vous avez besoin d’une toute nouvelle fonctionnalité, il vous suffit d’ajouter un nouveau système ou de modifier un système existant.

Ce que je n'ai pas trouvé autant discuté ailleurs, c'est à quel point cela facilite la maintenance, même dans des scénarios où il n'y a pas de changements de conception révolutionnaires que nous n'avions pas anticipés.Même en ignorant la flexibilité de l'ECS, cela peut vraiment simplifier les choses lorsque votre base de code atteint une certaine échelle.

Transformer des objets en données

Dans une précédente base de code lourde en POO où j'ai vu la difficulté de maintenir une base de code plus proche du premier graphique ci-dessus, la quantité de code requise a explosé parce que le code analogique Car dans ce schéma :

...devait être construit comme un sous-type (classe) complètement distinct implémentant plusieurs interfaces.Nous avions donc un nombre explosif d’objets dans le système :un objet séparé pour les lumières ponctuelles des lumières directionnelles, un objet séparé pour une caméra fish eye d'une autre, etc.Nous avions des milliers d'objets implémentant quelques dizaines d'interfaces abstraites dans des combinaisons infinies.

Lorsque je l'ai comparé à ECS, cela n'en nécessitait que des centaines et nous étions capables de faire exactement les mêmes choses avant d'utiliser une petite fraction du code, car cela transformait l'analogie. Car entité en quelque chose qui ne nécessite plus sa classe.Il se transforme en une simple collection de données de composants comme une instance généralisée d'un seul Entity taper.

Alternatives à la POO

Il existe donc des cas comme celui-ci où une POO appliquée en excès au niveau le plus large de la conception peut commencer à vraiment dégrader la maintenabilité.Dans la vue la plus large de votre système, il peut être utile de l'aplatir et de ne pas essayer de le modéliser si "profondément" avec des objets interagissant avec des objets interagissant avec des objets, même de manière abstraite.

En comparant les deux systèmes sur lesquels j'ai travaillé dans le passé et maintenant, le nouveau a plus de fonctionnalités mais nécessite des centaines de milliers de LOC.Le premier a nécessité plus de 20 millions de lignes de crédit.Bien sûr, ce n'est pas la comparaison la plus juste puisque le premier avait un héritage énorme, mais si vous prenez une tranche des deux systèmes qui sont fonctionnellement assez égaux sans l'héritage (au moins aussi proche de l'égalité que possible), le ECS prend une petite fraction du code pour faire la même chose, et en partie parce qu'il réduit considérablement le nombre de classes présentes dans le système en les transformant en collections (entités) de données brutes (composants) avec des systèmes lourds pour les traiter à la place. d'un bateau rempli d'objets petits/moyens.

Y a-t-il des scénarios où un paradigme vraiment non oop est en fait un meilleur choix pour une solution à grande échelle?Ou est-ce inconnu ces jours-ci?

C'est loin d'être du jamais vu.Le système que je décris ci-dessus, par exemple, est largement utilisé dans les jeux.C'est assez rare dans mon domaine (la plupart des architectures dans mon domaine sont de type COM avec des interfaces pures, et c'est le type d'architecture sur lequel j'ai travaillé dans le passé), mais j'ai constaté qu'en scrutant ce que font les joueurs quand concevoir une architecture a fait toute la différence en étant capable de créer quelque chose qui reste toujours très compréhensible tout en grandissant et en grandissant.

Cela dit, certaines personnes considèrent ECS comme un type de programmation orientée objet à part entière.Si tel est le cas, cela ne ressemble pas à la POO à laquelle la plupart d'entre nous penseraient, puisque les données (les composants et les entités qui les composent) et les fonctionnalités (les systèmes) sont séparées.Cela nécessite d'abandonner l'encapsulation au niveau général du système, qui est souvent considérée comme l'un des aspects les plus fondamentaux de la POO.

Codage de haut niveau

Mais il me semble que généralement les pièces de solutions de niveau supérieur sont presque toujours assemblées de manière OOP.

Si vous pouvez reconstituer une application avec du code de très haut niveau, elle a tendance à être plutôt petite ou moyenne en ce qui concerne le code que votre équipe doit maintenir et peut probablement être assemblée très efficacement à l'aide de la POO.

Dans mon domaine en VFX, nous devons souvent faire des choses qui sont de relativement bas niveau comme le lancer de rayons, le traitement d'image, le traitement de maillage, la dynamique des fluides, etc., et nous ne pouvons pas simplement les assembler à partir de produits tiers puisque nous sommes en fait en concurrence. plus en termes de ce que nous pouvons faire au bas niveau (les utilisateurs sont plus enthousiasmés par les améliorations de pointe et compétitives du rendu de production que, disons, par une interface graphique plus agréable).Il peut donc y avoir une très grande quantité de code allant du brassage de bits et d'octets de très bas niveau au code de très haut niveau que les scripteurs écrivent via des langages de script intégrés.

Interweb de Communication

Mais il arrive un moment avec une échelle suffisamment grande avec n'importe quel type d'application, de haut niveau ou de bas niveau ou un combo, qui tourne autour d'un état d'application central très complexe où j'ai trouvé qu'il n'était plus utile d'essayer de tout encapsuler. en objets.Cela tend à multiplier la complexité et la difficulté de raisonner sur ce qui se passe en raison de la quantité multipliée d’interactions qui se produisent entre tout.Il ne devient plus si facile de raisonner sur des milliers d'écosystèmes qui communiquent entre eux s'il n'y a pas un point de rupture à une échelle suffisamment grande où nous arrêtons de modéliser chaque chose comme des écosystèmes encapsulés qui doivent communiquer entre eux.Même si chacun est simple individuellement, tout pris dans son ensemble peut commencer à plus que submerger l'esprit, et nous devons souvent en prendre en compte beaucoup pour apporter des modifications et ajouter de nouvelles fonctionnalités et déboguer des choses, etc. essayez de faire évoluer la conception de tout un système à grande échelle uniquement autour des principes de la POO.Cela peut aider à se libérer de l’encapsulation à une certaine échelle pour au moins certains domaines.

À ce stade, il n'est plus nécessairement utile, par exemple, qu'un système physique encapsule ses propres données (sinon, de nombreuses choses pourraient vouloir lui parler et récupérer ces données ainsi que les initialiser avec les données d'entrée appropriées), et c'est là que J'ai trouvé cette alternative via ECS très utile, car elle transforme le système de physique analogique, et tous les systèmes aussi lourds, en un "transformateur de base de données central" ou un "lecteur de base de données central qui produit quelque chose de nouveau" qui peut désormais s'ignorer les uns les autres.Chaque système commence alors à ressembler davantage à un processus dans un pipeline plat qu'à un objet qui forme un nœud dans un graphe de communication très complexe.