Re: java ?

Ouais, mais non, pas en Java. Les guetter and setter n'encapsulent rien dans 90% des cas, ils sont justes auto générés et retournent la valeur, point.

Non ils retournent la référence, c'est là le vrai problème à mon avis.

foo.bar est plus sympa à lire que foo.getBar()

On est dans la subtilité, là. Juste une question de joli.

Surtout sur des créations/copies d'objets ou t'assignes 10 fields d'affilée.

Le problème n'est peut être pas dans les setters. Sauf cas particulier, je considère qu'il y a 2 grandes classes d'objet (il y en a d'autre comme les énumération par exemple, mais elles sont bien plus rare) :

• les beans, qui ne portent que de la donnée, en principe j'essaie qu'ils soient immutables (donc avec le(s) constructeur(s) qui va bien des getter (d'objets aussi immutables) et pas de setter) ou si vraiment la construction se fait en plusieurs fois j'utilise des setters de type builder qui te permettent d'écrire foo.setBar("toto").setBidule(42)
• les objets « de traitement » dont les données internes doivent rester interne. Donc le constructeur permet de lui injecter ses dépendances et c'est tout.

Exemple enswift, langage décent avec des vrai properties (il me semble que c# à un truc du genre aussi, mais je connais pas assez pour dire).

Euh... Si je comprends bien ton exemple, tu va faire un print à chaque affectation. Donc tu as un effet de bord lors de l'utilisation de foo.bar = "toto". C'est totalement opposé à ce que tu affirme juste au dessus :

Le fait que tout soit une fonction a aussi tendance à cacher le fait qu'un getter peut avoir un side effect/être cher à calculer, et ca c'est mal. si t'as un side effect notable, ça devrait être une fonction, pas get/set.

Je trouve au contraire qu'il est bien plus logique d'imaginer avec un effet de bord sur foo.setBar() (ou foo.bar(String)) que sur foo.bar = "".

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)