Il manque des infos sur ton pebkac. Si le paramètre id est une clef primaire, l'intérêt reste limité voir à proscrire. Si c'est pour un autre champ qui doit vérifier d'autres contraintes, c'est plus que nécessaire.
T'apprends donc autant prendre les bonnes habitudes, surtout si le projet va évoluer.

On va dire qu'ajouter des contrôles ou une abstraction à
machin.truc = bidule;

est plus difficile que
machin.setTruc(bidule);

L'utilisation d'un refactor n'est pas non plus évident.

Le pire dans tout cela c'est que les IDE intègrent des fonctions pour les créer automatiquement !

"des accesseurs et des mutateurs sont essentiels à l'utilisation de tels objets"
Si, j'ai déjà vu des cas où les getters/setters étaient obligatoire pour la sauvegarde des objets (avec une base MySQL, ou pour créer des fichiers XML).
D'ailleurs, c'est très chiant comme système.

Ben JPA, il me semble qu'il en a besoin pour extraire une interface.
Après tu as tout ce qui est Java remote object (RMI et EJB) où les interface sont plus que nécessaire.

« si des accesseurs et des mutateurs sont essentiels à l'utilisation de tels objets, non, ils ne sont pas obligatoires. »

Ça peut être essentiel sans être obligatoire ?

Ah, l'informatique et les modes... hier la mode du "tout XML", aujourd'hui la mode du "tout json" et "tout getter/setter"...
Et quel que soit votre avis sur les getters et setters, setID, qui modifie l'id d'un élément, c'est juste une hérésie. Depuis quand on change les id des éléments ?

L'utilisation des accesseurs et modificateurs est une bonne pratique qui permet de mettre en place une API propre sans être gêné plus tard pour modifier le fonctionnement interne d'une classe. Si tu prétends le contraire tu as peut être manqué quelque-chose en programmation objet et généricité (mais on va me dire hautain...)

Quant à l'obligation, certaines bibliothèques l'exigent en effet.

(De même que le constructeur par défaut vide)

KAMOULOX

Ben pour un de mes projets, l'ID d'un objet est crée dans des couches plus basses. L'algo ne permet pas de perdre d'ID. Je crée un objet sans ID, l'user le modifie. Quand il l'a fini, il l'envoie. C'est là que l'ID est attribué. J'ai donc besoin d'un setID. L'objet pouvant être complexe, l'action d'attribution répercute cet ID vers des sous-objets. Le méta objet ne contenant pas grand-chose.

Qué?

Je pense que ce qu'il faut comprendre dans ce pebkac : "modifier un identifiant technique n'est pas recommandé ni recommandable."

Et je suis d'accord avec ceci. Même si certains framework l'imposent.

Il faut une raison pour exposer une variable d'instance. Ce n'est pas systématique et heureusement. Si, en java, vous voulez implémenter une pile sans utiliser la classe standard Stack (parce que cette classe est une aberration). Vous pouvez réaliser, par exemple, cette implémentation en utilisant une variable d'instance de type List et vous n'allez pas exposez cette variable d'instance parce que cela casserait le contrat d'une Pile.

Les accesseurs et modificateurs sont pratiques mais leur utilisation ne démontrent pas la qualité d'une API.

Pour l'exemple des geters / seters, c'est avant tout un défaut de Java : un vrai langage objet permet de déclarer des propriétés, et donc de transformer un attribut en propriété au besoin.

Pas vraiment, c'est la même choses dans tout les langages objets.
Sauf que dans certain les accesseurs ne sont pas explicite et peuvent être surchargé.

J'ai déjà vu un truc du genre une fois, mais seulement parce que le besoin était trop éloigné du modèle de données (bravo /o/).

Sinon le xml c'est carrément pas sexy, en plus avec le json tu peux utiliser (cuir) mustache et rien que pour ce jeu de mots ça vaut le coup!

Sans getters/setters,tu casses l'encapsulation....pas oop comme truc...si en plus tu es en multithread,comment synchronises tu l'accès a ta classe?

Allez, un peu de lecture pour ceux qui ne développent pas sur Android et qui moins sent le pauvre Cartman. http://stackoverflow.com/questions/6716442/android-performance-avoid-i[...]

Courage Cartman.

Oui.
Par exemple:
Pour manger de pâtes il est essentiel de les cuire, mais ce n'est pas indispensable : on peut (techniquement) les manger crues, même si c'est moins pratique.

Ça dépend des langages, on peut utiliser les propriétés...

Pourquoi c'est toujours avec des chiffres qui sortent du chapeau ? Mais bon, passons.
Ca sent surtout que google n'a pas fini sont jit, car dans les prochaines releases ce n'est plus le cas.
Si la machinerie java ne les élimine pas pourquoi pourrir son code plutôt que de le confier à un optimisateur ?

Voilà un lien un poil plus sérieux.
http://developer.android.com/training/articles/perf-tips.html#GettersS[...]

Bien lire la note. Qui t'explique qu'il existe un obfuscateur qui optimise et élimine ce problème.

Je me souviens du jour où j'ai voulu stocker des objets d'un projet perso en XML...
Le code pour utiliser le parser XML de base de java était super long, les classes devaient être conçu d'une certaine façon... et tout ça pour me retrouver au final avec un fichier xml avec des balises "void".
Ouaip.
En voyant tout ça, je me suis dis "chouette, j'ai réussi à stocker des objets en XML comme tout le monde! :D ...c'est cool. :) ...ok, screw all that shit."
Et je me suis fais mon petit parser de fichier textes perso. Plus léger, plus facile à utiliser et à maintenir, bref, que du bonheur.
Le XML, je ne m'y ferais jamais.

"(mais on va me dire hautain...)"
Yup. :/

Je dirait même que sur Android, les bonnes pratiques voudraient que tu utilise un "Content-Provider" pour accèder à tes données (et encore plus si tu utilise du SQLite derrière...)

En fait, pour moi, en base de données, y'a toujours un champs ID et ce champs est toujours une clé primaire.
Autrement oui, j'ai bien précisé que les mutateurs et accesseurs sont essentiels, ce n'est pas pour autant qu'il y en a systématiquement, ce serait une faille possible dans notre système, ainsi dans le cas de champs normaux, c'est pas un soucis.
Après dans certains cas, le set doit prendre un objet non directement l'id de celui-ci mais ça c'est déjà moins grave que de vouloir modifier la clé primaire.

C'est tout à fait vrai.
On a même utilisé Alibaba (ORM pour Java/SPARQL), une vraie horreur, je pense que devant il faudrait un vrai objet pour assurer l'intégrité des données (ou avoir un truc qui fonctionne mieux qu'Alibaba :D).

Ca dépend de ce que tu modélise. Il n'y a pas toujours de id en clef primaire. Exemple des utilisateurs on peux utiliser leur email comme clef primaire. Ce qui optimise ta recherche au login et pass.

La clef primaire peut-être aussi sur plusieurs champs.
Quand tu fait une relation n:n J'espère que tu n'affuble pas la table relation par un id auto increment en vérifiant via un select que la relation n'existe pas déjà ;)

Je considère qu'aucune donnée fournie par l'utilisateur ne peut être utilisée comme clé primaire, c'est une donnée trop sensible.
De plus, l'entier est ce qu'il y a de plus simple à comparer et je suis toujours sûr qu'il est valide.
En plus, ça me permet de facilement généraliser mes systèmes.

Enfin, je vois pas trop en quoi mettre l'email en clé primaire optimise la recherche par login/pass... Au pire, tu mets un index dessus, c'est pareil dans tous les cas ?