[Java] comment bien utiliser les getters et setters en général?

Super, merci pour ces explications !!

C’est quoi DDD ? Pas trouvé sur Wikipédia :

https://fr.wikipedia.org/wiki/DDD

Bonjour, en java c’est tellement devenu une convention de faire des setter / getter, que l’éditeur Eclipse propose une génération automatique de code pour tous les attributs d’une classe. Et, du coup, c’est tellement devenu du code "redondant" qu’une lib java nous permet maintenant de même plus l’écrire, ça diminue drastiquement la lisibilité du code, qui est généré à la compilation, remplacé par une simple annotation, c’est lombok : https://projectlombok.org/features/Data qq1 sait s’il existe l’équivalent en php?

Génial, comment faire les accesseurs automatiquement ??

Vu qu’un de mes anciens posts a été référencé, je ne m’attarde pas pour insister sur tout le mal que je pense des setters.

Combien de fois as-tu professionnellement eu besoin de ça? Et saurais-tu estimer le temps que tu as gagné?

En ce qui me concerne, je n’ai pas souvenir d’avoir galéré une seule fois en une 20 aine d’années, et le temps gagné est conséquence du nombre de setters que j’ai su éviter (pour penser OO, i.e. services) depuis que j’ai pris conscience que l’on m’avait menti — pas nécessairement à escient, cf la guignolitude auto-alimentée évoquée par Michel (et requalifiée avec mes mots).

Pour l’instant mon choix est que je suis prêt à payer une erreur de compilation pour les cas où je change radicalement d’interface et que je ne puisse pas profiter d’inférence de type (avec auto, bossant essentiellement en C++). Après j’ai droit aux typedefs aussi, de fait, les quelques cas qui auraient pu être critiques ont dû être absorbés.

Pour l’exemple du Chat. Quel est le besoin véritable derrière ce SetNickname? Si on parle le nom, il est unique et affecté à la création, il n’a plus besoin de changer. Un surnom, ne sera pas unique et on pourra en rajouter, ou en enlever. Set n’est donc plus la bonne action.

Quant aux contrôles réalisés, je vois ici de la programmation excessivement défensive qui cherche à occuper le terrain de la programmation par contrat. C’est à l’appelant de vérifier les préconditions. Au niveau de l’appelé, on peut à la limite réaliser un contrôle supplémentaire pour balancer des exceptions de type erreur de programmation dans le but d’espérer de robustifier un code dans lequel il reste des erreurs une fois livré.

J’ai vu une conf il y a peu qui aborde le sujet et passe rapidement sur le cas de langages qui officialisent l’approche exceptions dans tous les sens, même si au final on ne sait pas trop quoi en faire. Je me demande si ce n’était pas dans le talk d’Herb Sutter au dernier ACCU — et j’aime beaucoup la direction qu’il prend à considérer que notre std::logic_error, en C++, était en toute logique une erreur de conception qui ne devrait pas exister.

Combien de fois as-tu professionnellement eu besoin de ça?

Assez souvent en fait (pas en Java, que j’ai la chance de ne pas utiliser); je développe du code qui est utilisé par pas mal de gens derrière, et non une application où tout le code est au même endroit et peut être mis à jour d’un seul coup. On a en plus des contraintes de compatibilité, des gens qui utilisent des anciennes versions de nos bibliothèques et qui veulent pouvoir écrire du code compatible avec à la fois les nouvelles et les anciennes versions.

Je ne veux pas dire qu’il faut mettre des setters partout par principe, mais il n’empêche que passer par une indirection de fonction plutôt que d’écrire directement dans des champs peut être utile en cas de changement de représentation. La compatibilité se pense en amont pour une partie si possible bien définie et pas trop grosse de l’interface qu’on expose, et le fait de se restreindre à passer par des setters peut être une des techniques mises en place.

Faut voir ça autrement

• de temps en temps on a besoin d’en faire
• il me semble (j’y connais rien en fait) qu’il en faut des tonnes avec les JavaBeans
• c’est complètement trivial, pour un IDE moderne, de proposer ce genre de trucs, comme les constructeurs, toString, hash et tutti quanti
• quand on en a besoin, ça prend deux secondes avec l’IDE

ce qui n’est absolument pas une raison pour en coller partout, et surtout en faire le paradigme pour modifier l’état d’un objet.

Malheureusement, les exemples de classes qu’on trouve dans la plupart des introductions à la POO, c’est des machins qui sont de simples agrégats de données dont la seule responsabilité identifiable est de contenir des champs. Au mieux on leur ajoute une méthode afficher(), ce qui est passablement idiot (il faut mieux que l’objet soit capable de fournir sa description textuelle, c’est pas son job de piloter la console).

Quand je dis que ça incite à faire des conneries, un exemple : une classe Personne, qui ont des surnoms. Stockés dans un attribut ArrayList<String>. Avec une methode ajouterSurnom(String surnomSupplémentaire). Jusque là tout va bien. Et là

class Personne {
    private ArrayList<String> surnoms;
    ...
    public ArrayList<String> getSurnoms() {
        return surnoms;
    }
}

What could possibily go wrong?, comme disait l’autre.

C’est quoi l’erreur avec getSurnoms() ?

Comment corriger ce problème ?

https://zestedesavoir.com/forums/sujet/12466/probleme-de-texte-message/

Alors que se passe t’il si j’essaye d’éviter les getters en faisant comme ça :

class Personnage {
    private Voiture voiture;
    private String marqueVoiture;

    public Personnage(Voiture v) {
        this.voiture = v;
        this.marqueVoiture = v.getMarque();
    }

    public void faireQqch() {
        qqch(this.marqueVoiture);
    }
}

Je procède comme ça pour respecter la loi de demeter et donc éviter à la ligne 11 :

qqch(this.voiture.getMarque());

Déjà, une personne peut avoir plusieurs voitures. Ou pas.

Avant d’appliquer la loi de Demeter, il faut commencer par avoir un truc qui tient debout…

class Voiture {
   String plaque;
   String getPlaque() { return plaque; }
   ...
}

class Personne {
   ArrayList<Voiture> voitures;

   void pourChaquePlaque(Consumer<String> action) {
       voitures.forEach(v -> action.accept(v.getPlaque());
   }
}


Personne p;
...
p.pourChaquePlaque(System.out :: println);

Dans ce cas pourquoi ne pas exposer un itérateur sur les voitures, qui donne plus de flexibilité qu’une approche fold comme pourChaqueVoiture?

désolé je suis un peu perdu dans mon projet pas sûr d’avoir le temps de réglèer les derniers détails, je vais donc en rester à la réponse de chinois furax pour les responsabilités