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?
Réponses:
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.
la source
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.
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.
la source
Je pense que votre idée de la POO est un peu décalée:
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.
la source
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.
la source
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.
la source