C'est beau.

Perso, je "sens" le PEBKAC sans le voir.... Mais c'est principalement due au fait que "mon Zgeg est meilleur en développement objet que moi"... :'(

Il était prof de composition artistique ?

Entre private et protected, c'est vrai que en cours c'est pas toujours évidant de faire comprendre la différence aux étudiants, mais vis-à-vis des public c'est quand même pas la même chose quoi u_u
Fin je sais pas genre "en private seul votre class peut utiliser ces éléments, alors qu'en public tout le monde peut les manipuler"

Après un simple exemple sur le fait que le public a pas le droit de rentrer dans les cuisines d'un restaurant, alors qu'ils peuvent utiliser les toilettes et basta, même sans avoir de notion de programmation tu a compris le principe... <_>"

J'espere vraiment que dans ton restaurant, les toilettes ne sont pas getters/setters de la cuisine ^^

Le principe de base (pour simplifier) de la POO c'est de donner le moins d'accès possible aux changements de valeurs des variables d'une classe aux autres classes.

En gros tu mets tous en private sauf quand tu n'as pas le choix et si possible tu mets protected et non public.
Pour ce qui est des accesseurs, les get servent à accéder à la valeur d'une variable et peuvent donc être public sans (grosses) conséquences par contre un set doit toujours être private pour qu'une variable ne puisse changer de valeur qu'uniquement par une fonction/procédure dédiée propre à la classe.

@Shadam : par contre un set doit toujours être private pour qu'une variable ne puisse changer de valeur qu'uniquement par une fonction/procédure dédiée propre à la classe
Euuuh non. Tout dépend de la variable et de l'objet, mais je vois bien plus souvent des setters publics que privés (je me demande d'ailleurs si j'en ai déjà vus des privés). Déjà parce qu'un setter privé ne sert à rien (ben oui la classe a déjà accès à la variable privée, donc tu ne protèges rien du tout), et ensuite parce que si tu as besoin de modifier un paramètre de ton objet depuis un autre objet il te faut bien appeler le setter qui est fait pour ça. A moins que tu n'écrives une autre méthode publique pour faire exactement la même chose que ton setter privé ? Mais dans ce cas tu as du code en doublon ce qui n'est pas une bonne chose.

La ou je suis plutot d'accord c'est dans le cas d'objects sans logique (uniquement attributs et getter/setter) genre les DTO ou les classes du modele en MDD.

C'est juste un libriste. Si vous voulez appliquer la licence GPL à votre logiciel, tous vos membres doivent être public.

Çà c'est une private joke

Amusant, finalement cette quote n'est pas autant un pebkac que ça.
La POO tel que je l'ai vu/compris : les getter et les setter sont public (sinon, ça n'a pas beaucoup d'utilité). Ensuite, ton objet ne se présente aux autre qu'a travers d'interfaces.
Au final, seul ton objet responsable de l'initialisation n'a accès au getter et setter.
C'est le principe de base d'un Bean en java.

http://lasante.net/1541-37610-large/aspegic-adultes-1000-mg-x-15.jpg

La boîte y est passée...... J'ai toujours rien piné... -_-

C'est con parce que j'ai "cru" avoir compris avec l'explication, et je pine plus rien après l'exemple..... u_u

Attend, l'Aspegic commence à faire effet....

Donc, si je comprends bien, tes chiottes et ta cuisine sont deux "Objets", c'est ça ? Que tu "coderai" en:
Public Chiottes
Private Cuisine

J'ai bon?

Si oui, je te félicite pour avoir réussi à m'expliquer le principe de classes publiques et privées. Y en a qui ont essayer, ils ont eu des problèmes!

"LE principe de la programmation objet" > le principe de la programmation objet, c'est pas plutôt de faire de l'objet tout simplement ? :p

« LE principe de la programmation objet »
Non, c'est uniquement la manière dont il est implémenté en Java. On peut très bien utiliser d'autres techniques que « attributs privés, getteurs & setteurs publiques » lors du design du langage, comme l'utilisation des propriétés.

Ce seraient plutôt deux membres d'un gros objet Restaurant.
Et autant tu veux bien que l'extérieur accède aux WC, et tu lui laisse en faire ce qu'il veut, autant tu laisses tes cuisines en "private" pour éviter de voir débarquer une inspection sanitaire / pour éviter que les gens qui emploient ton objet Restaurant ne fassent des bêtises dans la Cuisine.
En gros, la façon dont tes cuisines sont implémentées est opaque aux clients extérieurs.

Na, il étais plus question de méthode que de variable.
Pour les get/set, par juste du principe qu'on te demande la cuisson, mais qu'on te laisse pas aller cuire ta viande toi-même :P

Les getters et setters en programmation objet c'est le meilleur moyen de faire n'importe quoi comme briser son encapsulation comme un gros con. Par ailleurs, c'est complètement en opposition avec les principes SOLID. Fin bref : d'autres lectures par là : http://www.javaworld.com/article/2073723/core-java/why-getter-and-sett[...]

Finalement le pebkac n'est pas là où je le croyais. A mon avis c'est le pote qui n'a pas compris le prof.

Je sens venir que ce que le prof à dit ça à été dit alors justement qu'il y avait des accesseurs sans logique vers les données internes. Dans ce cas effectivement mettre les données internes en private ne sert à rien, autant les mettre en public.
Le prof n'a pas tord de dire que foutre des getteurs/setteurs partout ça ne protège pas. Comme il a raison de dire que si il y a des getteurs/setteurs partout c'est plus rapide de ne pas les mettre et de tout laisser en public.

Et je sens bien le coup de l'élève qui se souviens à moitié de l'évènement et qui rephrase un peu lors de la discutions.

Ca peux se concevoir pour le prof de dire quelque chose comme ça pour un exercice de base au début de l'apprentissage, mais si il n'a pas corrigé ses dires après alors pebkac pour lui. Si il a corrigé mais que le pote n'a pas écouté, pebkac pour le pote.

Le principe de la programmation objet c'est que tes objets sont opaques.

Lorsque tu utilises une bibliothèque te présentant des classes OO, tu n'y a accès que via l'interface, sans devoir te demander comment la classe fonctionne, et donc sans avoir besoin de savoir quels attributs elle utilise.

Si la classe te donne un setter sur une propriété, c'est pour te donner une façon de modifier l'objet, pas forcément juste l'attribut de l'objet (Un Setter peut modifier trois variables, invalider un booléen, etc).. Et si tu n'as pas de setter pour modifier une propriété que tu veux changer, c'est qu'elle n'est pas faite pour être modifiable (Ou que celui qui a fait la classe l'a oublié).

Donc oui, ça fait partie DU principe de base de la POO.

Venant du C et me remettant petit à petit au Java sur le code d'un collègue, ça m'a fait doucement marrer quand j'ai trouvé des classes ne contenant aucune fonction, uniquement des variables private et des getters/setters.
Pour moi, c'est l'équivalent d'un struct, et je ne vois pas l'intérêt dans ce cas là d'appliquer bêtement les préceptes du private. Dans le cas général, je suis d'accord avec le principe. Cela permet notamment d'ajouter des tests ultérieurement si nécessaire.
Mais dans l'absolu, n'avoir QUE du private... à ce compte là, pourquoi avoir un mot-clé public ?

Les getters et les setters ne servent pas à "protéger" (d'un point de vue sécurité applicative)... toutes tes variables sont accessibles par introspection, par exemple.

Les getters et les setters participent au principe d'encapsulation, qui est un des fondements de la POO. On ne modifie pas un objet, on lui demande de le faire, via des méthodes maîtrisés par celui-ci uniquement.

Pourquoi faire des getters / setters publiques qui récupèrent/modifient des attributs private ou protected?

Cela permet de ne faire apparaître, d'un point de vue utilisateur, que des méthodes et des propriétés dont la définition et le comportement réel est masquée. Cela permet une plus grande évolutivité : on peut modifier ce comportement sans impacter l'utilisateur.

Je préfère quand même les chiottes privés. :-/

Connaitre la différence entre private et protected permet d'avoir un énorme gain de temps quand on fait de l'héritage

Oui, je dit pas le contraire, mais les notions d'héritage sont déjà du N+1 vis-à-vis des bases de l'objet.

Tu gagne beaucoup de temps, mais techniquement tu peut t'en passer sans que ça soit trop nuisible (alors que entre le private/public ça peut poser des problèmes)

@Epok__ :
Le problème des getters et setters, c'est plus le fait que l'utilisation devient dépendante de l'implémentation, donc une modification profonde de l'objet entraîne presque fatalement modification de code utilisateur, ce qu'on cherche à tout prix à éviter en objet.
Néanmoins, avoir tous les champs internes privé et uniquement des fonctions de manipulation en public permet de cantonner les contrôles de contrat (assert), en particulier l'invariant de l'objet (qui est hyper important), à l'objet lui-même. Formellement, c'est plus "sain".
D'ailleurs en C, on préférera cacher la gueule de la structure dans un fichier C et donner uniquement des fonctions de manipulation dans le header, remplissant le même office, mais c'est plus galère d'utilisation.

Une propriété ce n'est pas la même chose qu'un champ : https://en.wikipedia.org/wiki/Property_%28programming%29

BLorf, ya plein de langages qui sont en full public et qui se retrouve bien plus propres que du Java.

A moins, on se retrouve pas ave des classes de 300 lignes remplies de fonctions tellement utiles telles que:
int getA() { return self.a: }

alors qu'une bon object_instance.a est quand même plus rapide à écrire.

Ya un moment, faut faire confiance aux développeurs. Je ne compte plus les fois où j'ai du passer un temps monstre à faire du vieux copy-paste de lib alors qu'une simple surcharge, doublé d'un accès aux attributs privés, n m'aurait pris que 10 minutes.

L'objet c'est classe, mais le principe de base était mal branlé. On s'en est rendu compte assez vite mais trop tard : Java était là et tous les dev qui vont avec.

La force de l'objet c'est rendre les structures de données opaque et cantonner les invariants. Le problème, c'est les programmeurs au rabais pas foutus de le comprendre (comprendre : les gens qu'on forme en deux mois au langage Java et qu'on proclame "expert du langage" et qui sont (trop) nombreux).
Typiquement, une classe avec des getters/setters sur les attributs internes, c'est tout sauf de l'objet. 'fin bon j'ai déjà filé des arguments plus haut et un lien intéressant, donc je vais pas recommencer ici.

Oublis les chiottes, c'est pas un bonne exemple du coup.

Prend juste l'objet cuisine :
- toutes ses variables sont privé (elle sont à la cuisine, tu a pas à y toucher)
- tu dispose de set/get public pour agir sur les variables (genre ton n° de table ou ton étage)
- les méthodes (fonctions de la classe) sont public ou privée en fonction de ce qu'elle font.

La méthode commander() est public, alors que mettre_a_cuire() est privé et ne peut être lancer que par la classe si elle ne trouve pas de problème.

Je ne parlais pas d'une propriété dans le sens programmation, mais dans le sens courant.

Et sinon, les langages objet qui n'ont pas de méthodes privées et pour lesquels les setters et les getters sont déconseillés, vous connaissez ?
(au pif, Python).

Non, les méthodes privées ce n'est pas LE principe de la programmation objet.
Oui, je suis d'accord avec le prof.

Les méthodes privées ce n'est pas obligatoire... Il faut juste que les choses soient claires et que les classes soient bien documentées...

Je parle des setters "complexes" qui contiennent des listes par exemple.

public List<monObjet> CurrentList { get; private set; }

Et avec la méthode qui va bien

 public void SetCurrentList(List<monObjet> list)
 {
    // Les tests qui vont bien
    this.CurrentList = list;
 }
 

Evidemment si c'est pour la propriété ID d'un objet tu ne t'emmerdes pas public int ID { get; set; }