Je suis un programmeur débutant, j'aimerais savoir ce qu'est et à quoi sert réellement la programmation orientée objet ?
Version Courte:
La programmation orientée objet est un paradigme de programmation impérative. Elle sert à faciliter la modélisation du programme lors de la phase de conception.
Wow, minute, attend, qu'est-ce que quoi ? Paradigme ? Modélisation ? On va y aller doucement, avec la…
Version Longue:
Un paradigme, déjà, c'est quoi ? Grossièrement, c'est une façon de programmer. En réalité, ça va un peu plus loin. En effet, le langage façonne la pensée (c'est à dire, qu'on pense avec les mots dont on dispose, et non qu'on crée des mots pour exprimer des concepts que l'on pense sans mots pour les nommer), et ça n'est pas très différent en informatique: le paradigme va façonner votre façon de concevoir votre programme (pour le meilleur et pour le pire).
Il y a beaucoup de paradigmes, de sous-paradigmes, de sous-sous-sous-paradigmes, ils se croisent, s'entrecroisent, on en utilise en général plusieurs à la fois, même si on n'en a pas conscience, et ils sont plus ou moins compatibles entre eux.
Dans la programmation impérative, on pense le programme comme la suite des transitions entre ses états possibles, lesquelles transitions sont le produit du code écrit par le développeur. On dit au programme comment il doit accomplir son changement d'état. Par exemple, en C, on change l'état du programme en déclarant l'existence d'une variable, puis on change l'état de cette variable en lui assignant une valeur, etc.
Cela s'oppose à la programmation déclarative, dans laquelle on décrit l'état désiré, et on laisse l'implémentation du langage gérer la transition. Par exemple, en SQL, on décrit l'état désiré (je veux une base dans tel état après une insertion, ou une mise à jour, avec telles conditions, etc) et on laisse l'implémentation gérer la transition.
La programmation impérative est très certainement le paradigme que vous utilisez, peut-être sans le savoir. Parmi les sous-paradigmes de la programmation impérative, on trouve la programmation procédurale (ou orientée procédure), et la programmation orientée objet. Dans ces deux paradigmes, on définit des procédures et des fonctions.
Une procédure est une suite d'instructions qui va changer l'état du programme. C'est un peu comme une fonction (dans beaucoup de langages impératifs, les deux mots sont utilisés de façon quasi-interchangeables), sauf que ça ne retourne pas de résultat. Ca change juste l'état du programme. Pensez au mot-clef void dans les langages C, C++, C# ou Java. Il définit une procédure.
La limite peut être floue. On peut avoir des procédures qui retournent un résultat pour indiquer si elle se sont déroulées correctement (et éventuellement, comment elles ont échoué, le cas échéant). Par exemple, la méthode add qu'on retrouve sur les collections (Set, List, Queue, etc) en Java est une procédure, puisqu'elle existe pour changer l'état de la collection en y ajoutant des données, mais elle retourne un booleen qui vaut vrai si l'ajout a bien été fait, et faux si la donnée n'a pas été ajoutée pour n'importe quelle raison (par exemple, si on tente d'ajouter une donnée dans un Set alors qu'il contient déjà cette donnée)
Ou à l'inverse, on peut avoir des fonctions qui modifient l'état du programme, en plus de retourner leur résultat (on appelle ça un effet de bord), par exemple une fonction qui modifierait un ou plusieurs de ses paramètres passés en référence.
En programmation procédurale, on sépare très fortement l'état du programme de ses transitions. L'état correspond aux données, ses transitions correspondent aux procédures. Le programme se pense alors comme la succession des procédures (lesquelles peuvent appeler des fonctions, ou d'autres procédures). Le paradigme procédural est quasiment systématiquement celui qui est utilisé lorsqu'on apprend les bases de la programmation. Si vous êtes très débutant, c'est probablement celui que vous utilisez.
En programmation orientée objet, cette séparation n'est pas aussi nette. On définit des objets, qui contiennent des membres. Ces membres peuvent être des données (des variables) qui définissent l'état de l'objet, on parle alors d'attributs; ou des procédures (et des fonctions), qui définissent la façon dont l'objet peut transitionner entre ses états, on parle alors de méthodes. On regroupe alors ensemble les données et le code qui va agir sur ces données. Le programme se pense alors comme l'ensemble des objets qui le composent.
Voilà pour ce qu'est la programmation orientée objet. Maintenant, voyons à quoi elle sert.
L'avantage de la programmation procédurale est qu'elle facilite énormément la conceptualisation du déroulement du programme. Elle convient très bien aux programmes qui utilisent un faible niveau d'abstraction (systèmes d'exploitations, pilotes de périphériques, etc). A l'inverse, la programmation orientée objet facilite la modélisation des états du programme, tout en restant dans un paradigme impératif, ce qui peut bien convenir à des programmes qui exploitent un plus fort niveau d'abstraction (applications de bureau, web services, etc).
Elle sert donc à faciliter (par rapport à la programmation procédurale) la conception du programme, dans certaines circonstances. Elle est très utilisées, car il se trouve que ces circonstances constituent la majorité des cas d'utilisation de la programmation impérative.
Par Antoine Berbineau
Depuis Quora :
https://fr.quora.com/Je-suis-un-programmeur-d%C3%A9butant-jaimerais-savoir-ce-quest-et-%C3%A0-quoi-sert-r%C3%A9ellement-la-programmation-orient%C3%A9e-objet