La POO n'est pas importante pour elle-même, mais pour ce qu'elle implique. Quelque chose qui traite de la capacité d’abstraction et d’isolement, de regrouper des éléments et d’exposer uniquement les éléments nécessaires pour interagir ensemble.
Il s'agit d'une technique d'ingénierie courante appelée "modularisation", qui permet de créer des systèmes complexes en tant qu'agrégation de systèmes simples, sans s'occuper de tous les détails à un niveau élevé, et qui exigent que les composants soient remplaçables, même sans qu'ils soient exactement les mêmes. même.
On a essayé de garder ces "concepts d'ingénierie" dans le développement logiciel à partir du moment où le produit logiciel lui-même était devenu plus grand que la "capacité de développeur unique", exigeant donc un moyen de faire en sorte que les développeurs travaillent sur des pièces indépendantes, interagir ensemble.
Cela dit, ces principes ne se retrouvent pas nécessairement uniquement dans la programmation orientée objet (si la théorie du calcul est valide, il existe une infinité de méthodes pour obtenir ces résultats).
La programmation orientée objet est simplement une tentative réussie de regrouper ces éléments, en donnant à ces termes généraux (tels que modules, encapsulation, substitution) des définitions plus précises et une conceptualisation élaborée de ces définitions (modèles) pouvant s'intégrer dans les langages de programmation.
Pensez d'abord à la programmation orientée objet, non pas comme une " fonctionnalité linguistique ", mais comme un " lexique commun " " permettant aux ingénieurs en logiciel de se familiariser avec la conception du logiciel.
Le fait qu’une langue donnée ait ou non des primitives qui appliquent directement ce lexique garantissant, par exemple, qu’une "capsule" n’est pas ouverte par inadvertance par celui qui n’est pas censé le faire est un aspect secondaire de la conception de la programmation orientée objet. C'est pourquoi même les grands projets C sont souvent "gérés en tant que" POO, même si le langage lui-même n'offre aucun support direct à cela.
L’avantage de tout ce qui n’est pas reconnaissable jusqu’à ce que la taille d’un projet reste inchangée est la capacité d’un développeur unique à comprendre et à suivre tout ce qu’il fait (en fait, dans une telle situation, cela peut même être perçu comme un "frais généraux"), ou encore à un petit groupe une courte période. Et c’est la raison principale pour laquelle les juniors qui ont étudié la POO en terme de "fonctionnalité de langage" l’interprètent souvent mal en produisant un code mal conçu.
La manière dont la POO s’intègre dans les langues dépend de la façon dont les concepteurs de langue interprètent le principe de la POO dans leur propre construction.
Ainsi, "encapsulation" en C ++ devient "membres privés" (et une "capsule" devient une classe), "substitution" devient une fonction virtuelle annulant ou paramétrisation / spécialisation de modèle, etc., tandis qu'en D une capsule est un "module" (et la substitution va etc.), rendant ainsi certains paradigmes ou modèles directement disponibles dans une langue donnée et non dans une autre, etc.
Ce que les recruteurs cherchent en posant la question de la programmation orientée objet, c’est simplement vérifier votre capacité à résumer et à concevoir des logiciels pour les futurs grands projets et développements. OOP, pour eux, ce n’est qu’un "dictionnaire", ils ont supposé que vous et eux le saviez afin que vous puissiez parler d’autres choses plus générales ou se concrétiser dans une implémentation spécifique.