Quand j'ai pour ainsi dire marché sur Internet, j'ai remarqué une caractéristique intéressante. Tous les paradigmes de programmation discutés ailleurs sont perçus par les gens assez calmement. Si, par exemple, ils parlent de programmation procédurale, alors ils en parlent de manière absolument calme. La même chose concerne la programmation modulaire. Programmation déclarative - pas de tempêtes, troubles ou holivarov. La programmation fonctionnelle est la même.
Et seulement autour de la POO ne calme pas les tempêtes.
Certains crient de joie, d'autres, au contraire, trouvent à redire sur quoi est basée la lumière. Et pour être honnête, il est totalement incompréhensible pour moi que le monde entier se soit réuni en POO.
Vous venez peut-être de penser que je suis plus un adversaire qu'un défenseur de la POO. Ce n'est absolument pas le cas (cependant, vous pouvez le comprendre à partir du titre). Non. Je suis plutôt un adversaire des balles d'argent, du battage médiatique, de l'intronisation d'une certaine méthodologie ou personne, et de toutes sortes de danses rondes. Vous ne conduisez pas de danses rondes, disons, une clé ou une tondeuse à gazon. Et n'écrivez pas, j'espère, des publications pour lesquelles une perceuse ou un marteau craint.
Mais aujourd'hui, tout Internet regorge d'articles pompeux, hyperémotionnels et radicaux sur la POO - si l'un dit que la POO est «zer gut» et en général à tous les tripes, alors les autres diffusent nécessairement que la POO doit être jetée à la poubelle de toute urgence (ne serait-ce que il ne partage pas le point de vue du premier). Il n'y en a pas de troisième.
Je veux juste apporter le troisième élément. C'est calme, sans battage médiatique et abus, de dire pourquoi la POO n'est pas un élixir de toutes les maladies, mais aussi, comme le PP, la FA ou le PL, a le droit d'exister.
Donc, un article calme pour défendre la POO. Dans ce document, j'essaierai d'examiner les principaux arguments des opposants à l'OLP et de justifier leur échec.
1. Tout ce qui existe dans la POO est depuis longtemps dans d'autres paradigmes
Presque tous les langages de programmation sont complets, à l'exception des langages de balisage, tels que HTML, XML, CSS, etc. Parlant dans une langue paysanne, Turing est une langue complète - une langue dans laquelle vous pouvez écrire absolument n'importe quel programme imaginable. De là découle une thèse assez générale: ce qui est dans n'importe quelle langue choisie au hasard l'est dans toutes les autres langues. On peut en dire autant des paradigmes. Toutes les différences de langues (et de paradigmes) sont différentes manières d'implémenter certaines commandes, sans compter les caractéristiques lexicales individuelles.
Soit dit en passant, la même thèse (tout ce qui est en N, en M, en K et en R, etc.) peut être formulée comme suit: le marteau est déjà composé de fer et de bois, pourquoi avons-nous également besoin de pinces? Mais personne ne le dira.
2. La POO mélange les données et les actions à leur sujet. C'est mauvais
L'argument est aspiré du doigt. Premièrement, où la POO mélange-t-elle les données et les fonctions? Deuxièmement, l'affirmation selon laquelle cela est mauvais est également tirée d'une lanterne, d'un baril "un vrai homme ne fait pas ça", et pourquoi - à cause du glaïeul. La POO modélise en quelque sorte le monde réel où les données sont inhérentes à l'objet - personne ne prétendra que la chaise manque de couleur et n'a pas quatre pieds. Et aucun mélange de données et d'opérations n'a lieu ici, l'objet n'est pas une fonction ou un opérateur.
Ceci est une abstraction.3. L'héritage asservit le programme, rend les changements difficiles
Ici, vous pouvez ralentir un peu. La succession n'implique nullement la construction d'arbres kilométriques afin de ralentir le développement. L'héritage a été inventé afin de distinguer les propriétés et méthodes communes dans une superclasse, et cela doit être fait avec des classes représentant des objets du même type. Ce sera une erreur de créer, par exemple, deux classes, dont l'une est l'héritière de l'autre, car il n'y a pas d'allocation d'un code commun à une superclasse simplement parce
qu'il n'y a rien en commun .
S'il n'est pas destiné à étendre la classe parente à une troisième classe, un tel héritage n'a tout simplement aucun sens. Si vous créez un magasin d'alcools, les classes de bière, de vodka et de vigne peuvent être héritées de la classe d'alcool, mais vous n'avez pas du tout besoin de créer la classe de boissons, sauf si vous voulez vendre, disons, du thé paraguayen.
En outre, ce sera une erreur de créer des hiérarchies dans lesquelles les classes ne sont pas liées les unes aux autres. Eh bien, pourquoi, dites-moi, pour faire une tour où les classes Fly et Cutlet sont héritées de la superclasse Cheese, qui, à son tour, est héritée de la superclasse vendredi?! Mais ce n'est plus un défaut de POO, mais les mains tordues de celui qui le compose.
4. L'encapsulation n'a pas de sens
Ici, je suis partiellement d'accord. Du point de vue du programme, l'encapsulation n'affecte vraiment rien. Si je ferme la variable à l'aide de private - alors quoi, je peux toujours l'ouvrir en supprimant simplement private, puis changer tout ce que j'aime.
Mais cela n'est vrai que techniquement. La philosophie de la POO est qu'une classe correctement organisée et encapsulée peut être considérée comme une boîte noire. Imaginez une boîte sur un côté de laquelle se trouvent divers boutons, des emplacements pour fournir des données et de l'autre - un emplacement de sortie qui renvoie des informations. Prenons, par exemple, une pile. Imaginez une boîte sur un côté de laquelle il y a un emplacement pour insérer des données et un bouton-poussoir à côté. Au dos se trouve le bouton pop. Vous soumettez une note avec le numéro 8 et appuyez sur le bouton-poussoir. Ensuite, vous donnez un autre morceau de papier et appuyez sur push pour la deuxième fois. Et donc N fois, puis appuyez sur pop. Un morceau de papier sort du tiroir avec le numéro 76 (ou un autre, en général, celui que vous avez soumis). Besoin d'un autre numéro? Appuyez une deuxième fois sur pop. Et ainsi de suite jusqu'à la
conspiration de la
carotte jusqu'à ce que la boîte soit vide. Et si vous continuez à pousser le pop, le mécanisme de la boîte va conquérir: la pile est vide! C'est exactement à quoi ressemble l'objet.
Mais une fois que vous avez créé et configuré la classe, vous savez déjà comment cela fonctionne là-bas - cela fonctionne juste correctement, mais vous n'avez pas besoin d'en souhaiter plus. Et encapsulant toutes ces structures, vous ne gardez pas tout en mémoire. Ils (beaucoup de cases) se parlent simplement comme vous l'avez configuré.
L'encapsulation est une sorte de béquille qui prend en charge les centaines de piliers de votre programme pendant que vous en construisez cent et unième. Dans les grands projets (à savoir, pour les créer, OOP a été inventé) sans cela, hélas, rien.
Bien qu'il ne soit guère "hélas" généralement approprié ici.
5. Il n'y a pas de hiérarchies de relations dans le monde réel, seulement des hiérarchies d'inclusion partout
En est-il vraiment ainsi? Mais personne ne se soucie de créer, par exemple, une hiérarchie où tous les fleuves du monde (Congo, Seine, Tamise, Amazonie, Kolyma, etc.) sont les objets d'un "fleuve" complet, qui a des propriétés inhérentes (par exemple, se compose d'eau) et actions (par exemple, les débits), et déjà il sera hérité de l '"étang", qui se compose également d'eau, et de l' "étang", vous pouvez également hériter du "lac", dont les objets seront des lacs séparés (Baïkal, mer Caspienne, Titicaca, etc. .d.). Le schéma est assez rude. Mais les hiérarchies relationnelles sont aussi une
abstraction . Quelque chose d'une idée platonicienne, si vous voulez. Dans le monde réel, ils ne sont pas là, ils n'existent que dans l'esprit, c'est une généralisation, et rien de plus. Mais c'est précisément la façon dont une personne pense très souvent. On peut dire «chaussette» sans préciser de quelle couleur il s'agit, de quel matériau il est tissé, etc., mais cette «chaussette» existe-t-elle vraiment?
Néanmoins, nous ne devons pas être gênés qu'il n'y ait ni «objet» ni «chaussette».
6. La méthodologie de la POO est initialement erronée
Un argument absolument infondé. La POO a été créée afin de simuler une sorte de monde virtuel composé d'objets, comme notre monde. Par exemple: une personne est un objet du monde réel. Il peut marcher, courir, manger,
chier , jouer au football, regarder le football, mais, malheureusement, je ne peux pas tout énumérer ici et honnêtement, ce serait dégoûtant de tout énumérer. Cette même personne a les propriétés suivantes: présence / absence de cheveux, couleur des cheveux, le cas échéant, couleur des yeux,
s'il s'agit de la couleur de la peau, nombre de doigts, etc. Si vous construisez correctement tous les champs et méthodes, comme je l'ai écrit ci-dessus, l'objet programme pourra modéliser certaines propriétés d'un objet réel. Une personne pense très bien dans ces catégories - c'est pourquoi la POO s'est généralisée. Cela aide beaucoup lors de l'écriture de grands projets, car il introduit la modularité et vous permet de diviser un progiciel en composants séparés qui interagissent les uns avec les autres.
7. Mais même des millions de mouches ne nous convaincront pas que le fumier est délicieux.
L'argument le plus populaire contre la POO. Par exemple, les masses sont pour la plupart stupides (mais je ne pense pas que cela s'applique également aux programmeurs), parcourez les "vêtements à la mode" et admirez-les.
Mais pensez-y, et sinon l'OLP, mais, disons, LP, était entré dans le piédestal? Pensez-vous que ce serait différent? Rien de tel! Il y aurait eu des fans et des adversaires malveillants, et ils auraient considéré l'OLP comme un instrument (à cela, j'appelle en fait), et non comme une pilule créée par Dieu lui-même et donc irremplaçable.
Pourquoi cet article défend-il l'OLP?
Tous les discours modernes sur les paradigmes de programmation, selon moi, se résument à deux prémisses diamétrales: quitter OOP et jeter le reste, ou jeter OOP et ... eh bien, vous me comprenez.
Je ne veux pas qu'un paradigme tout à fait approprié soit considéré comme un dépotoir digne, mais je ne veux pas de danse ronde autour de lui, mais j'ai tout oublié. Je pense que le second est plus facile à faire, mais cet article est dirigé contre le premier.
Si vous n'aimez pas la POO
À qui - OOP, à qui - FP, à qui - PP. Et pour quelqu'un, peut-être, en général, le cartilage de porc est surtout sucré. Si vous n'aimez pas les chats, vous ne savez probablement pas comment les faire cuire.