{"id":116,"date":"2021-06-25T19:13:31","date_gmt":"2021-06-25T19:13:31","guid":{"rendered":"https:\/\/www.louismarchand.me\/?p=116"},"modified":"2021-06-30T15:20:38","modified_gmt":"2021-06-30T15:20:38","slug":"pourquoi-je-naime-pas-la-portee-privee","status":"publish","type":"post","link":"https:\/\/www.louismarchand.me\/index.php\/2021\/06\/25\/pourquoi-je-naime-pas-la-portee-privee\/","title":{"rendered":"Pourquoi je n’aime pas la port\u00e9e priv\u00e9e"},"content":{"rendered":"

\u00c0 quoi sert la port\u00e9e priv\u00e9e<\/h2>\n

Toute personne ayant d\u00e9velopp\u00e9 dans un langage de programmation orient\u00e9 objet bas\u00e9 sur le C++ (Java, C#, etc.) conna\u00eet la port\u00e9e priv\u00e9e. Cette port\u00e9e d’attribut ou de m\u00e9thode permet de s’assurer qu’aucune autre classe n’aura acc\u00e8s \u00e0 l’attribut ou \u00e0 la m\u00e9thode en question. Cette port\u00e9e sert principalement \u00e0 prot\u00e9ger l’int\u00e9grit\u00e9 des valeurs d’un objet. Par exemple, si j’ai la classe Java suivante dans laquelle je mets l’enti\u00e8ret\u00e9 de mes attributs publics:<\/p>\n

\n
public<\/span> class<\/span> Personne<\/span> {<\/span>\r\n\r\n    public<\/span> String<\/span> nom<\/span>;<\/span>\r\n\r\n    public<\/span> int<\/span> age<\/span>;<\/span>\r\n\r\n}<\/span>\r\n<\/pre>\n<\/div>\n
Le client de ma classe peut donc assigner n’importe quelles valeurs aux attributs de ma classe. Par exemple, ce code Java serait valide:<\/p>\n
\n
Personne<\/span> lPersonne<\/span> =<\/span> new<\/span> Personne<\/span>();<\/span>\r\nlPersonne<\/span>.<\/span>nom<\/span> =<\/span> \"\"<\/span>;<\/span>\r\nlPersonne<\/span>.<\/span>age<\/span> =<\/span> -<\/span>8<\/span>;<\/span>\r\n<\/pre>\n<\/div>\n
Le probl\u00e8me ici, c’est que malgr\u00e9 que le code est valide, les valeurs entr\u00e9es ne font aucun sens. En effet, une personne ne peut pas avoir aucun nom et un age n\u00e9gatif. C’est la raison pour laquelle nous pouvons utiliser des accesseurs et des assignateurs (\u00ab\u00a0getter\u00a0\u00bb et \u00ab\u00a0setter\u00a0\u00bb). Je pourrais donc mettre mes attributs priv\u00e9s, les rendres accessibles par des accesseurs et valider les valeurs par des assignateurs. Voici l’exemple Java modifi\u00e9:<\/p>\n
\n
public<\/span> class<\/span> Personne<\/span> {<\/span>\r\n\r\n    private<\/span> String<\/span> nom<\/span>;<\/span>\r\n\r\n    public<\/span> String<\/span> getNom<\/span>()<\/span> {<\/span>\r\n        return<\/span> nom<\/span>;<\/span>\r\n    }<\/span>\r\n\r\n    public<\/span> void<\/span> setNom<\/span>(<\/span>String<\/span> aNom<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aNom<\/span> !=<\/span> null<\/span> &&<\/span> !<\/span> aNom<\/span>.<\/span>isEmpty<\/span>()){<\/span>\r\n            nom<\/span> =<\/span> aNom<\/span>;<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"Le nom n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n    private<\/span> int<\/span> age<\/span>;<\/span>\r\n\r\n    public<\/span> int<\/span> getAge<\/span>()<\/span> {<\/span>\r\n        return<\/span> age<\/span>;<\/span>\r\n    }<\/span>\r\n\r\n    public<\/span> void<\/span> setAge<\/span>(<\/span>int<\/span> aAge<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aAge<\/span> >=<\/span> 0<\/span>){<\/span>\r\n            age<\/span> =<\/span> aAge<\/span>;<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"L'age n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n}<\/span>\r\n<\/pre>\n<\/div>\n
On voit maintenant que le client de la classe ne peut plus acc\u00e9der directement aux attributs puisque ces derniers sont priv\u00e9s. Le client doit maintenant utiliser les assignateurs (\u00ab\u00a0setNom\u00a0\u00bb et \u00ab\u00a0setAge\u00a0\u00bb) pour assigner des valeurs aux attributs. De plus ces assignateurs ont un m\u00e9canisme d’exceptions leur permettant de v\u00e9rifier que les valeurs sont correctes avant d’effectuer l’assignation de l’attribut.<\/p>\n
Le priv\u00e9 dans le contexte d’h\u00e9ritage<\/h2>\n
Les clients de la classe ne sont pas les seules entit\u00e9s pouvant assigner de mauvaises valeurs dans les attributs de l’objet. Cette probl\u00e9matique s’applique \u00e9galement aux descendants de la classe. Par exemple, si je faisais la class Bebe qui repr\u00e9sente une Personne d’age entre 0 et 1. Il est possible dans ce cas que les parents n’aient pas encore trouv\u00e9 de nom pour ce b\u00e9b\u00e9. Je pourrais avoir le code Java suivant:<\/p>\n
\n
public<\/span> class<\/span> Bebe<\/span> extends<\/span> Personne<\/span> {<\/span>\r\n\r\n    @Override<\/span>\t\r\n    public<\/span> void<\/span> setNom<\/span>(<\/span>String<\/span> aNom<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aNom<\/span> !=<\/span> null<\/span>){<\/span>\r\n            nom<\/span> =<\/span> aNom<\/span>;<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"Le nom n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n    public<\/span> void<\/span> setAge<\/span>(<\/span>int<\/span> aAge<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aAge<\/span> >=<\/span> 0<\/span> &&<\/span> aAge<\/span> <=<\/span> 1<\/span>){<\/span>\r\n            age<\/span> =<\/span> aAge<\/span>;<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"L'age n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n}<\/span>\r\n<\/pre>\n<\/div>\n
Il est important de voir que ce code ne compilera pas puisque les attributs nom et age sont priv\u00e9s et ne peuvent donc pas \u00eatre assign\u00e9. On peut utiliser les assignateurs de la classe Personne pour faire le travail. Dans ce cas, j’aurais le code Java:<\/p>\n
\n
public<\/span> class<\/span> Bebe<\/span> extends<\/span> Personne<\/span> {<\/span>\r\n\r\n    @Override<\/span>\t\r\n    public<\/span> void<\/span> setNom<\/span>(<\/span>String<\/span> aNom<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aNom<\/span> !=<\/span> null<\/span>){<\/span>\r\n            super<\/span>.<\/span>setNom<\/span>(<\/span>aNom<\/span>);<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"Le nom n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n    @Override<\/span>\t\r\n    public<\/span> void<\/span> setAge<\/span>(<\/span>int<\/span> aAge<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aAge<\/span> >=<\/span> 0<\/span> &&<\/span> aAge<\/span> <=<\/span> 1<\/span>){<\/span>\r\n            super<\/span>.<\/span>setAge<\/span>(<\/span>aAge<\/span>);<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"L'age n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n}<\/span>\r\n<\/pre>\n<\/div>\n
Dans ce cas, le \u00ab\u00a0setAge\u00a0\u00bb fonctionnera sans probl\u00e8me puisque la particularit\u00e9 de Bebe (age entre 0 et 1) est conforme \u00e0 la condition de personne (age plus grand ou \u00e9gal \u00e0 0). Par contre, le \u00ab\u00a0setNom\u00a0\u00bb ne fonctionnera pas puisque le \u00ab\u00a0setNom\u00a0\u00bb de Bebe accepte les cha\u00eenes vide, mais le \u00ab\u00a0setNom\u00a0\u00bb de Personne les refuses.<\/p>\n
Le probl\u00e8me<\/h2>\n
Maintenant que nous avons bien pr\u00e9cis\u00e9 \u00e0 quoi sert la port\u00e9e priv\u00e9e, je peux pr\u00e9senter le probl\u00e8me. Je veux pr\u00e9ciser que tous les cas pr\u00e9sent\u00e9s plus haut sont tout \u00e0 fait corrects et permettre de montrer que la port\u00e9e priv\u00e9e permet de bien valider les valeurs assign\u00e9es aux attributs de la classe.<\/p>\n
Le probl\u00e8me est au niveau id\u00e9ologique, mais peut avoir des r\u00e9percussions au niveau fonctionnel.<\/p>\n
Au niveau id\u00e9ologique, c’est que la port\u00e9e priv\u00e9e ne respecte pas le principe de programmation orient\u00e9e objet. En effet, l’h\u00e9ritage dans le principe de programmation orient\u00e9e objet est un lien de sp\u00e9cialisation\/g\u00e9n\u00e9ralisation (l’enfant sp\u00e9cialise et le parent g\u00e9n\u00e9ralise). Par exemple, une Pomme est une version sp\u00e9cialis\u00e9e d’un Fruit, qui lui est plus g\u00e9n\u00e9ral. En d’autres mots, l’enfant repr\u00e9sente une sous-cat\u00e9gorie du parent, avec des particularit\u00e9s suppl\u00e9mentaires. Donc, une Pomme est un Fruit, avec des particularit\u00e9s suppl\u00e9mentaires (forme, couleur, go\u00fbt, etc.).<\/p>\n
Le probl\u00e8me repose ici. L’enfant ne doit pas \u00eatre consid\u00e9r\u00e9 comme quelque chose de distinct du parent. L’enfant compl\u00e8te le parent. Il s’agit du m\u00eame objet vu d’un angle diff\u00e9rent (plus g\u00e9n\u00e9ral ou plus sp\u00e9cifique). Il est donc compl\u00e8tement illogique qu’il existe des choses (au sens large) que le parent peut faire, mais que l’enfant ne peut pas faire (l’inverse n’est pas vrai puisque l’enfant sp\u00e9cialise le parent). En d’autres mots, puisque la Pomme est un Fruit, la Pomme devrait avoir acc\u00e8s \u00e0 tout ce que le Fruit a acc\u00e8s.<\/p>\n
Puisque la port\u00e9e priv\u00e9e permet de rendre accessible certains attributs et m\u00e9thodes au parent qui n’est pas accessible aux enfants et que dans le principe de programmation orient\u00e9e objet, l’enfant devrait avoir acc\u00e8s \u00e0 tout ce que le parent a acc\u00e8s, on en d\u00e9duit que la port\u00e9e priv\u00e9e n’est pas conforme au principe de programmation orient\u00e9e objet.<\/p>\n
Cette probl\u00e9matique peut \u00e9galement avoir un effet au niveau fonctionnel. En effet, il arrive souvent qu’on cr\u00e9e des attributs en lecture seul dans une classe. Afin de faire ce type d’attribut, on utilise un attribut priv\u00e9 qui ne contient qu’un accesseur ou \u00ab\u00a0getter\u00a0\u00bb (pas d’assignateur ou \u00ab\u00a0setter\u00a0\u00bb). Ce faisant, les classes descendantes se retrouvent \u00e0 ne plus avoir de contr\u00f4le sur un de leurs propres attributs. Il est bien entendu possible de mettre un assignateur prot\u00e9g\u00e9, mais il arrive souvent que la classe que nous souhaitons h\u00e9riter n’est pas une classe que nous pouvons modifier facilement (par exemple, classes de librairie) et il est donc compl\u00e8tement impossible d’y ajouter des assignateurs prot\u00e9g\u00e9s.<\/p>\n
\u00c0 propos de la port\u00e9e prot\u00e9g\u00e9e<\/h2>\n
La port\u00e9e prot\u00e9g\u00e9e r\u00e8gle en effet le probl\u00e8me de non-conformit\u00e9 au principe de programmation orient\u00e9e objet. En mettant toutes nos attributs et m\u00e9thodes d’impl\u00e9mentation en port\u00e9e prot\u00e9g\u00e9e, nous nous assurons que les descendants de la classe ont acc\u00e8s \u00e0 l’enti\u00e8ret\u00e9 de leurs m\u00e9thodes et attributs.<\/p>\n
Par contre, un autre probl\u00e8me survient, en mettant tous en port\u00e9e prot\u00e9g\u00e9e, on se retrouve avec une classe qui ne peut plus prot\u00e9ger l’int\u00e9grit\u00e9 de ces valeurs. La seule solution consiste en fait en s’assurant de mettre tous les attributs priv\u00e9s et de mettre toutes les m\u00e9thodes (incluant les accesseurs et les assignateurs) soit prot\u00e9g\u00e9s ou publics. De plus, il faut s’assurer de toujours mettre des assignateurs et des accesseurs \u00e0 tous les attributs, peu importe que ce soit des attributs en lecture ou en \u00e9criture seulement, ou bien des attributs\/variables d’impl\u00e9mentation de la classe. De cette mani\u00e8re, malgr\u00e9 que le code ne respecte toujours pas le principe de programmation orient\u00e9e objet (puisque les attributs ne sont pas directement accessibles par les descendants de la classe), on se retrouve tout de m\u00eame avec quelque chose de relativement fiable.<\/p>\n
Quels sont les alternatives?<\/h2>\n
Lors de l’\u00e9criture de son livre \u00ab\u00a0Object-Oriented Software Construction\u00a0\u00bb, un des livres les plus influant du domaine de la programmation orient\u00e9e objet, le chercher Bertrand Meyer a trouv\u00e9 une solution tr\u00e8s \u00e9l\u00e9gante \u00e0 ce probl\u00e8me: les invariants de classe.<\/p>\n
L’id\u00e9e d’un invariant de classe, c’est d’\u00e9tablir dans la classe (ainsi que dans les classes descendantes), une liste de r\u00e8gles qui doivent toujours \u00eatre respect\u00e9es dans les objets qui instancient cette classe. En d’autres mots, il n’est pas de la responsabilit\u00e9 des assignateurs de la classe de valider les valeurs de la classe, mais bien \u00e0 la classe elle-m\u00eame. Puisque les invariants sont h\u00e9rit\u00e9s et document\u00e9s, tous les anc\u00eatres de la classe h\u00e9ritent de ces invariants et ont l’obligation de les respecter. Lorsqu’une m\u00e9thode se termine, tous les invariants sont valid\u00e9s et si un de ces invariants n’est pas valide, une exception est lanc\u00e9e.<\/p>\n
Voici un exemple d’invariant fait dans le langage Java en utilisant une librairie de contrat (Java ne g\u00e8re pas les contrats par d\u00e9faut):<\/p>\n
\n
@Contract<\/span>(<\/span>\r\n           nom<\/span> !=<\/span> null<\/span> &&<\/span>\r\n           !<\/span>nom<\/span>.<\/span>isEmpty<\/span>()<\/span> &&<\/span>\r\n           age<\/span> >=<\/span> 0<\/span>)<\/span>\r\npublic<\/span> class<\/span> Personne<\/span> {<\/span>\r\n\r\n    protected<\/span> String<\/span> nom<\/span>;<\/span>\r\n\r\n    public<\/span> String<\/span> getNom<\/span>()<\/span> {<\/span>\r\n        return<\/span> nom<\/span>;<\/span>\r\n    }<\/span>\r\n\r\n    public<\/span> void<\/span> setNom<\/span>(<\/span>String<\/span> aNom<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aNom<\/span> !=<\/span> null<\/span> &&<\/span> !<\/span> aNom<\/span>.<\/span>isEmpty<\/span>()){<\/span>\r\n            nom<\/span> =<\/span> aNom<\/span>;<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"Le nom n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n    protected<\/span> int<\/span> age<\/span>;<\/span>\r\n\r\n    public<\/span> int<\/span> getAge<\/span>()<\/span> {<\/span>\r\n        return<\/span> age<\/span>;<\/span>\r\n    }<\/span>\r\n\r\n    public<\/span> void<\/span> setAge<\/span>(<\/span>int<\/span> aAge<\/span>)<\/span> {<\/span>\r\n        if<\/span> (<\/span>aAge<\/span> >=<\/span> 0<\/span>){<\/span>\r\n            age<\/span> =<\/span> aAge<\/span>;<\/span>\r\n        }<\/span> else<\/span> {<\/span>\r\n            throw<\/span> new<\/span> IllegalArgumentException<\/span>(<\/span>\"L'age n'est pas valide.\"<\/span>);<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n\r\n}<\/span>\r\n<\/pre>\n<\/div>\n
Cette technique a l’avantage de prot\u00e9ger enti\u00e8rement les attributs de la classe, et ce, m\u00eame si les attributs sont directement assignables par les descendants de la classe. De plus, cette m\u00e9thode respecte enti\u00e8rement le principe objet puisque l’invariant s’applique autant \u00e0 la classe Personne qu’\u00e0 ses descendants. En d’autres mots, contrairement au mot cl\u00e9 priv\u00e9 qui enl\u00e8ve de l’information aux descendants de la classe, l’invariant qui permet la m\u00eame protection des donn\u00e9es, est une information qui est h\u00e9rit\u00e9e (demeure donc accessible) dans les descendants.<\/p>\n
Petite parenth\u00e8se par rapport \u00e0 la port\u00e9e prot\u00e9g\u00e9e en Java<\/h2>\n
Les cr\u00e9ateurs de langage ont souvent une certaine obsession de s’assurer de garder minimal le nombre de mots cl\u00e9s dans le langage. Il s’agit en effet d’un \u00e9l\u00e9ment int\u00e9ressant, car plus le langage est minimal, plus il sera facile de cr\u00e9er le compilateur ou l’interpr\u00e9teur et plus il sera facile d’apprendre le langage. Par contre, certains mauvais \u00ab\u00a0desing\u00a0\u00bb de langage peut appara\u00eetre suite \u00e0 cette pr\u00e9occupation.<\/p>\n
La port\u00e9e prot\u00e9g\u00e9e de Java est un excellent exemple de cela. Initialement, la port\u00e9e prot\u00e9g\u00e9e permettait de permettre \u00e0 la classe en cours ainsi qu’\u00e0 ces descendants d’acc\u00e9der \u00e0 des attributs ou des m\u00e9thodes de la classe. Comme nous l’avons vu, cette port\u00e9e est tr\u00e8s int\u00e9ressante puisqu’elle permet de respecter le principe de programmation orient\u00e9e objet.<\/p>\n
Par contre, il existe un autre type de port\u00e9, plus rare et dont l’utilisation est plus subtile, mais qui peut, dans certains cas, \u00eatre tr\u00e8s int\u00e9ressant \u00e0 avoir dans un langage. Il s’agit de la port\u00e9 ami. Cette port\u00e9e permet \u00e0 certaines autres classes du syst\u00e8me, en plus de la classe en cours et des descendants, d’avoir acc\u00e8s aux attributs ou m\u00e9thodes. Il pourrait \u00eatre int\u00e9ressant par exemple pour la classe Tableau de g\u00e9rer une autre classe Cellule, mais sans que d’autres clients puissent utiliser cette Cellule. Le Tableau serait donc consid\u00e9r\u00e9 comme un ami de Cellule et en tant qu’ami, il aurait acc\u00e8s \u00e0 certains attributs et certaines m\u00e9thodes de Cellule qui ne sont pas publics.<\/p>\n
De mani\u00e8re \u00e0 pouvoir permettre ce type de port\u00e9e, mais en r\u00e9utilisant un type de port\u00e9e qui existait d\u00e9j\u00e0 dans le langage, Java a ajout\u00e9 comme r\u00e8gle \u00e0 sa port\u00e9e prot\u00e9g\u00e9e indiquant qu’en plus de la classe en cours et de ses descendants, l’attribut ou la m\u00e9thode prot\u00e9g\u00e9e serait accessible \u00e0 partir de toutes les classes du \u00ab\u00a0package\u00a0\u00bb en cours.<\/p>\n
Cette m\u00e9canique cause plusieurs probl\u00e8mes.<\/p>\n
Premi\u00e8rement, la port\u00e9e prot\u00e9g\u00e9e, qui je le rappelle est la seule mani\u00e8re en java d’avoir un attribut ou une m\u00e9thode d’impl\u00e9mentation dans une classe tout en respectant le principe de programmation orient\u00e9e objet, devient accessible par d’autres classes, ce qui contrevient au principe de masquage d’information de la programmation orient\u00e9e objet. Il en revient qu’en Java, la seule mani\u00e8re de faire des classes qui respectent les principes de programmation orient\u00e9e objet (autre que des classes ne contenant que des m\u00e9thodes publiques), c’est de faire une classe par \u00ab\u00a0Package\u00a0\u00bb, ce qui est loin d’\u00eatre propre ou m\u00eame pratique.<\/p>\n
Ensuite, consid\u00e9rant la mani\u00e8re que la majorit\u00e9 des programmeurs \u00e9crivent du code, on voit qu’il est tr\u00e8s rare qu’il y a une grande quantit\u00e9 de \u00ab\u00a0package\u00a0\u00bb Java. On obtient donc que le fait de faire des attributs ou des m\u00e9thodes prot\u00e9g\u00e9es revient g\u00e9n\u00e9ralement \u00e0 faire des attributs ou des m\u00e9thodes publics (ou presque). Ce fait peut causer de grande confusion puisque le compilateur laissera passer des manipulations qui clairement auraient d\u00fb \u00eatre interdites.<\/p>\n
Enfin, cette probl\u00e9matique fait que plusieurs programmeurs (particuli\u00e8rement les programmeurs avec peu d’exp\u00e9rience) comprennent mal la port\u00e9e prot\u00e9g\u00e9e, ne l’utilise que tr\u00e8s peu, ou inversement l’utilise toujours au lieu d’utiliser la port\u00e9e publique.<\/p>\n
Il aurait donc \u00e9t\u00e9 plus acceptable de cr\u00e9er une m\u00e9canique de port\u00e9e diff\u00e9rente \u00e0 la port\u00e9e prot\u00e9g\u00e9e pour g\u00e9rer la port\u00e9e amie en Java.<\/p>\n","protected":false},"excerpt":{"rendered":"
\u00c0 quoi sert la port\u00e9e priv\u00e9e Toute personne ayant d\u00e9velopp\u00e9 dans un langage de programmation orient\u00e9 objet bas\u00e9 sur le C++ (Java, C#, etc.) conna\u00eet la port\u00e9e priv\u00e9e. Cette port\u00e9e d’attribut ou de m\u00e9thode permet de s’assurer qu’aucune autre classe n’aura acc\u00e8s \u00e0 l’attribut ou \u00e0 la m\u00e9thode en question. Cette port\u00e9e sert principalement \u00e0… Continue reading Pourquoi je n’aime pas la port\u00e9e priv\u00e9e<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,6],"tags":[7,8],"class_list":["post-116","post","type-post","status-publish","format-standard","hentry","category-programmation","category-programmation-orientee-objet-programmation","tag-programmation","tag-programmation-orientee-objet","entry"],"_links":{"self":[{"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/posts\/116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/comments?post=116"}],"version-history":[{"count":7,"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/posts\/116\/revisions"}],"predecessor-version":[{"id":126,"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/posts\/116\/revisions\/126"}],"wp:attachment":[{"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/media?parent=116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/categories?post=116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.louismarchand.me\/index.php\/wp-json\/wp\/v2\/tags?post=116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}