Avantages de la POO classique par rapport au langage Go-like

13

J'ai beaucoup réfléchi à la conception du langage et aux éléments qui seraient nécessaires pour un langage de programmation "idéal", et étudier Go de Google m'a amené à remettre en question de nombreuses connaissances par ailleurs communes.

Plus précisément, Go semble avoir tous les avantages intéressants de la programmation orientée objet sans avoir réellement la structure d'un langage orienté objet. Il n'y a pas de classes, seulement des structures; il n'y a pas d'héritage de classe / structure - seulement incorporation de structure. Il n'y a aucune hiérarchie, aucune classe parente, aucune implémentation d'interface explicite. Au lieu de cela, les règles de conversion de type sont basées sur un système lâche similaire à la saisie de canard, de sorte que si une structure implémente les éléments nécessaires d'un "Reader" ou d'une "Demande" ou d'un "Encodage", alors vous pouvez la convertir et l'utiliser. comme un.

Y a-t-il quelque chose à propos de la POO implémentée en C ++ et Java et C # qui est intrinsèquement plus capable, plus maintenable, en quelque sorte plus puissant que vous devez abandonner lorsque vous passez à un langage comme Go? À quoi devez-vous renoncer pour gagner la simplicité que représente ce nouveau paradigme?

EDIT
Suppression de la question «obsolète» que les lecteurs semblaient trop accrocher et rendre furieux.

La question est, qu'est-ce que le paradigme traditionnel orienté objet (avec des hiérarchies et autres) comme on le voit fréquemment dans les implémentations de langage commun a à offrir qui ne peut pas être fait aussi facilement dans ce modèle plus simple? Ou, en d'autres termes, si vous deviez concevoir un langage aujourd'hui, y a-t-il une raison pour laquelle vous voudriez inclure le concept de hiérarchies de classes?

tylerl
la source
1
La POO a-t-elle rendu la programmation procédurale obsolète? Je déteste avoir l'air pédant ou que je vous parle, mais c'est la première phrase qui m'est venue à l'esprit. Go fournit un nouveau paradigme (ish). Avec l'expérimentation, les utilisateurs découvriront à quoi ils sont bons et à quoi ils ne sont pas bons (comme avec tous les paradigmes et langages), et nous nous retrouverons avec des centaines d'excellents produits (avec sa juste part de mauvais produits) écrits en Go . Du moins, c'est mon opinion
Jamie Taylor
1
Il y a quelques lectures intéressantes lorsque votre Google pour OOP est mort . Je recommande The Web Will Die When OOP Dies
Andomar
La POO a tellement peu de valeur que cela ne vaut pas la peine de perdre votre temps.
SK-logic
1
Je suis d'accord avec le commentaire précédent, ne vous concentrez pas trop sur la POO. Outre OOP ne signifie pas C ++ ou Java. Essayez de lire abit sur ltu.org
AndreasScheinert
C ++, Java et C # ne sont pas des langages OOP "classiques". S'il existe un langage OOP classique, je pense que c'est Smalltalk.
kevin cline

Réponses:

16

Il n'y a pas de nouveau paradigme. L'orientation des objets est un modèle que vous utilisez pour écrire des programmes, qui n'est même pas clairement défini. Différents langages fournissent divers traits typiques de l'orientation d'objet (définition de nouveaux types, encapsulation, hiérarchies de types, polymorphisme, passage de messages et plus) mais peuvent ne pas en fournir d'autres. Dans ces cas, il appartient aux programmeurs de les émuler si le besoin s'en fait sentir.

La plupart des langages qui fournissent ces fonctionnalités n'ont pas d'analogue du concept de classe - par exemple Javascript et Common Lisp. L'implémentation fournie par les langages de type Java (basés sur les classes, avec héritage unique, interfaces, répartition basée sur le type) n'est qu'une des possibilités, et pas nécessairement la meilleure.

Andrea
la source
11
+1 pour "pas nécessairement le meilleur". Citant Alan Kay: "J'ai inventé le terme orienté objet, et je peux vous dire que je n'avais pas le C ++ en tête." (il n'avait pas non plus C # et / ou Java, je suppose humblement)
herby
1
@herby, je l'ai vu suggérer que les systèmes d'agents (similaires à la façon dont Erlang fonctionne) sont plus proches de l'intention finale d'Alan Kay pour la POO.
CodexArcanum
2
Euh, Common Lisp a définitivement des cours. Mais, typiquement, une classe CL contient des données et des méthodes sont définies sur des "fonctions génériques". En tant qu'effet secondaire, cela vous donne un moyen pratique de faire une répartition multiple, car les méthodes ne sont plus étroitement couplées à "une seule classe d'implémentation".
Vatine
Oui, ce que je voulais dire, c'est qu'il n'a pas de cours au sens de Java
Andrea
5

À quoi devez-vous renoncer pour gagner la simplicité que représente ce nouveau paradigme?

La vérification de type pour un système de type structurel est beaucoup plus complexe que la simple vérification si la classe de base se trouve dans votre liste d'héritage. La répartition virtuelle devient un peu plus délicate et probablement moins performante.

Un tel système obsolète-t-il le concept de POO?

Non. Tant que vous pouvez faire le programme en termes d '«objets qui font des choses» plutôt que d'une liste d'instructions, ou d'un ensemble déclaré de règles, ou d'une série de fonctions en cascade ... l'implémentation n'a pas d'importance. De même, la modification du système de type n'invalide aucun des principes OO courants.

Vous pouvez toujours travailler sur un type de base et ne pas vous soucier de son type réel. Vous pouvez toujours étendre des types sans les modifier. Vous pouvez toujours faire qu'un type ne fasse qu'une seule chose. Vous pouvez toujours fournir des interfaces à grain fin. Vous pouvez toujours fournir des abstractions à vos types.

Comment une langue permet cela n'a pas vraiment d'importance.

Telastyn
la source
En fait, Go , toutes ces choses POO plus facile et ajoute quelques possibilités supplémentaires comme extension pour fournir un type nouvelle interface application aux instances existantes (aussi longtemps que vous n'avez pas besoin de nouveaux membres de données, bien sûr).
Jan Hudec
4

Je pense que votre idée de la POO est un peu décalée:

J'ai inventé le terme «programmation orientée objet» et ce {Java et C ++} n'est pas ce que j'avais en tête.
- Alan Kay .

Le choix du typage (sous-typage nominatif, sous-typage structurel ou typage canard - ou une combinaison de ceux-ci) est largement orthogonal à la POO. L'héritage et les classes sont entièrement orthogonaux à la POO. Si vous prenez le temps de jouer avec io, vous le verrez.

Vous pouvez maintenant demander quels types de systèmes de type sont «meilleurs» et quels sont les moyens de réutilisation et de combinaison de code. Et essayez de déterminer les avantages et les inconvénients entre les choix effectués dans Simula (et plus tard dans C ++, Java et C #) et ceux effectués dans Go. Mais ce sont toutes des questions différentes et distinctes.

En fin de compte, la POO est un concept très vague et toutes les tentatives de mise en œuvre se déclinent en une grande variété de saveurs. Mais pour vraiment simplifier les choses, je dirais que l'idée de base de la POO est de composer des systèmes de sous- systèmes SOLIDES . Maintenant, cela brouille absolument la ligne vers d'autres paradigmes, mais je suppose que c'est la raison pour laquelle les langues multi-paradigmes ont récemment gagné en popularité et pourquoi Google a pris son propre parti avec Go.

back2dos
la source
2
La question concerne les concepts, pas nécessairement le terme. Si vous pouvez trouver un meilleur nom que "POO" pour faire référence au concept de hiérarchies de classes et à tous les ajustements qui en découlent, alors nous pouvons l'utiliser à la place.
tylerl
@tylerl: Vous confondez au moins deux questions en une. La première est de savoir si le sous-typage structurel est meilleur que le sous-typage nominatif. L'autre est fondamentalement, si la composition est meilleure que l'héritage. Ces questions sont mutuellement orthogonales. Je pense que finalement la "meilleure" langue ne fait pas ce choix pour vous. Je suppose que Go a simplement un ensemble de problèmes différent, mais nous verrons si Google ajoute ces fonctionnalités "en arrière" ou non.
back2dos
J'aimerais un seul langage qui possède la plupart des capacités de C ++ mais était plus petit et plus simple. C ++ est le seul langage sauf C réaliste pour les noyaux, et il vous donne des outils extrêmement utiles comme les destructeurs et la STL. Et le principe important «si vous ne l'utilisez pas, vous ne le payez pas». OO, utilisé correctement, est extrêmement puissant. Mais les génériques et autres concepts non OO sont également d'une importance vitale. C ne vous donne presque rien, et Go jette de véritables OO pour de nouvelles idées étranges.
Erik Alapää
1

La POO n'est pas obsolète.

Comme l'a dit Andrea, de nombreux concepts ont été proposés comme alternative aux classes (par exemple: classe de types haskell). La POO a un gros avantage: elle est enseignée dans de nombreux endroits et la culture de la POO est largement partagée par les développeurs.

Cela permet une communication plus riche au sein d'une équipe. On peut parler plus facilement des usines que des prépromorphismes zygohistomorphes . La POO structure la façon dont vous organiserez et communiquerez sur votre programme avec des diagrammes couramment utilisés. C'est un atout puissant.

Simon Bergot
la source
1
Je pense: rires à plusieurs endroits. N'est-ce pas un avantage, en fait.
AndreasScheinert
@AndreasScheinert pourquoi ne serait-ce pas un avantage?
Simon Bergot
Parce que pour porter un jugement, vous devez connaître au moins 1 alternative tout aussi bonne. C'est un problème d'habitude, les gens aiment rester dans leur zone de confort et cela conduit à la stagnation.
AndreasScheinert
@AndreasScheinert utilise le bon outil pour le travail. Oop ne fonctionne pas pour tous les scénarios .... n'a rien à voir avec leur zone de confort
pqsk
1

Non, il n'y a rien de nouveau ici, et la POO n'est pas obsolète. C ++ a aussi des interfaces implicites sous forme de modèles, mais les gens utilisent toujours des fonctions virtuelles. Vous avez besoin d'interfaces explicites pour gérer, par exemple, des interfaces binaires ou des interfaces où l'autre code n'est tout simplement pas connu au moment de la compilation.

Vous pourriez faire valoir qu'il s'agit simplement d'un cas d'inférence par rapport à un énoncé explicite, ce qui ne ressemble en rien à un «nouveau paradigme» et vraiment juste plus pratique.

DeadMG
la source