human
Qu'est-ce que le code orienté objet ? J'en ai entendu parler mais je ne trouve pas d'explication que je comprenne Expliquez comme si j'avais cinq ans.
gpt
C'est surtout un mot à la mode : un terme sans grand sens auquel s'accrochent des tonnes de gens pour prouver qu'ils se conforment à une mode. Le terme a été inventé par [ Alan Kay ] ( URL_1 ) pour décrire le [ langage informatique Smalltalk ] ( URL_0 ) qu'il a inventé avec ses collègues . Smalltalk était différent de la plupart des langages de programmation de l' époque car il avait ces fonctionnalités : 1 . Toutes les procédures sont regroupées dans des * * classes * * qui définissent les types d' objets dans le programme et les opérations que vous pouvez effectuer avec eux . Vous pourriez donc avoir une classe Circle qui dit que , si vous avez un cercle , les opérations prises en charge obtiennent son rayon et sa circonférence . Les opérations d'une classe sont appelées * * méthodes * * . 2 . Les classes peuvent être liées les unes aux autres par une * * hiérarchie d' héritage * * qui définit un ensemble de relations " est une " . Vous pouvez faire de Circle une sous-classe d'une autre classe appelée Shape , car un Circle " est une " Shape . Si vous avez une classe Rectangle , vous pouvez également en faire une sous-classe de Shape . La classe Shape aurait des méthodes qui représentent des fonctionnalités communes à toutes les formes, comme le calcul de l'aire. 3 . Les sous-classes peuvent * * remplacer * * les méthodes de leurs super-classes. Si Shape a une méthode pour calculer une surface , Circle est également autorisé à fournir sa propre méthode à la place de celle - ci . 3 . L'exécution des opérations fonctionne par * * envoi de messages * * et * * envoi dynamique * * . Si vous avez un objet forme et que vous voulez calculer l'aire d'une forme, vous "envoyez un message" à l'objet lui demandant de calculer sa propre aire. Ce message est ensuite « distribué » à la meilleure méthode pour l'exécuter en vérifiant si la classe de l'objet a une méthode pour ce message, et si ce n'est pas le cas, en vérifiant la superclasse de l'objet, la superclasse de la superclasse, et ainsi de suite jusqu'à ce que vous trouviez une classe qui a une méthode ( ou vous n'en avez pas , auquel cas il y a une erreur de programme ) . Maintenant , voici les problèmes : * Les gens ne peuvent pas être d' accord sur ce que signifie " orienté objet " . Pour la plupart des choses que j'ai mentionnées ci-dessus, il y a quelqu'un qui prétendra qu'un point ou un autre dans cette description n'est pas pertinent. Ainsi, certaines personnes prétendront que la programmation orientée objet n'a pas besoin de classes (comme dans le langage Javascript), ou que vous pouvez avoir des classes mais que les opérations et les méthodes n'ont pas besoin d'être contenues dans des classes (comme dans Common Lisp) . Ou vous aurez des gens qui prétendent que les hiérarchies d'héritage ne sont pas une partie importante de la POO. * Il y a aussi un tas de choses que beaucoup de soi-disant "experts" de la programmation orientée objet jettent dans la discussion et prétendent être "essentiels", tout en se disputant pour savoir s'ils ont raison. Ou ils élaborent les concepts ci-dessus de manière étrange, comme la distinction entre la programmation orientée objet et la conception orientée objet ou autre. * Ensuite, il y a beaucoup de choses que les gens ont appelées "orientées objet" simplement parce que c'est un mot à la mode et pour que leurs produits ou leurs idées sonnent mieux aux yeux des ignorants. C'est un peu comme commercialiser un ensemble de haut-parleurs analogiques conventionnels en l'appelant " prêt pour le numérique ". s'étend à prétendre que quelque chose qui a été inventé par la programmation orientée objet alors que ce n'était pas le cas. Ainsi, par exemple, vous trouverez régulièrement des programmeurs orientés objet en ligne qui vous diront que * * l'encapsulation**—la technique qui consiste à cacher les détails internes d'un code à un autre code qui l'utilise—est une invention POO, ou même exclusive. à la POO , quand ( a ) elle a été inventée avant la POO , ( b ) elle existe dans toutes sortes de langages qui ne sont pas OO . Ainsi, vous verrez des mordus de la programmation orientée objet entrer dans des arguments de langage de programmation où ils prétendront que les langages non-OO sont mauvais parce qu'ils manquent d'encapsulation ; alors vous leur ferez remarquer que beaucoup de ces langages ont l'encapsulation, puis ils prétendront que ces langages l'ont copié de la POO. * Les hiérarchies de classes orientées objet sont généralement une manière horrible de concevoir et d'organiser des programmes. Il y a deux symptômes majeurs : le [problème cercle-ellipse] (URL_3) et le [problème de superclasse fragile] (URL_4). Le problème cercle-ellipse survient parce que votre programmeur OOP typique pense que parce qu'un cercle est un type d'ellipse, il s'ensuit que vous devriez faire de Circle une sous-classe d'Ellipse dans votre programme - et ce type de pensée conduit à des programmes vraiment mal conçus qui sont difficiles à maintenir et à modifier. Le problème de la superclasse fragile survient parce que définir une sous-classe en héritant d'une superclasse, vous ne définissez pas exactement de quelle manière la sous-classe s'appuie sur le comportement de la superclasse, puis quand quelqu'un arrive et essaie de corriger des bogues dans la superclasse, il changer son fonctionnement et cela crée des bogues dans la sous-classe . * Le problème fragile de la classe bas est souvent reconnu par les gourous de la POO , qui alors , au lieu de tirer la conclusion raisonnable que la POO n'est pas une approche universelle de la conception des langages de programmation et de l' architecture logicielle , ils ont en quelque sorte conclu que l' héritage n'est pas la " vraie POO " et que la vraie POO est en réalité * * composition * * , encapsulation et * * types de données abstraits * * ( que les gourous de la POO ont renommés " interfaces " ou " héritage d' interface " ) . Ce sont essentiellement les techniques pré-OOP, mais que les gourous de la POO impliquent ou même prétendent avoir été inventées par la POO. * Les programmeurs orientés objet de base ont * entendu * tout cela mais ne le * comprennent * pas. Ils continuent donc à utiliser l'héritage en toute liberté, ce qui conduit à un code très mal écrit. Les gourous savent que c'est un problème , mais leur solution n'est pas " bon sang , débarrassons - nous de la programmation orientée objet " , mais plutôt " bon sang , lançons des sociétés de conseil pour se faire payer des sommes obscènes pour avoir perpétué le système . causer le problème. " Ce qui est triste, bien sûr, c'est que l'industrie informatique est dominée par ces charlatans et leurs langages de programmation irréfléchis. Donc, pour apprendre à être un "bon" programmeur Java, vous devez tout apprendre sur l'héritage (puisque Java l'a comme caractéristique centrale du langage, vous devez l'utiliser) et ensuite vous devez apprendre des techniques élaborées pour éviter de l'utiliser (appelés "modèles de conception"). Vous devez apprendre quelque chose appelé ["modélisation de domaine"] (URL_2) qui consiste essentiellement à concevoir votre programme pour qu'il rencontre le problème cercle-ellipse. Il vous est interdit d'utiliser ou même d'apprendre la technologie des bases de données relationnelles au niveau de détail qu'il vous est demandé d'apprendre en POO. Vous pouvez écrire un programme absolument magnifique à votre travail qui résout son problème de manière performante et réutilisable, et quand vous arriverez à la révision du code, les "experts" OOP de votre équipe le réviseront mal parce que vous n'en aviez pas assez « orientation objet » en elle. Et ainsi de suite . Donc , TL;DR : la programmation orientée objet c'est beaucoup de conneries .