Les getters/setters, dans la plupart des cas, ne sont pas nécessaires et ils pollutent notre code, rendent le code plus long, les classes plus ouvertes (sans la vrai nécessité) donc plus vulnérables face au changement et la maintenance plus difficile.
Examinons le code suivant:

	private int height; 
	
	public void setHeight(int height) {
		this.height = height;
	}
	public int getHeight() {
		return height;
	}


D’abord, on déclare la propriété “height” en privé, biensûr, pour cacher l’information – comme on a tout appris dans les principes de la programmation orienté-objet. Mais juste après, on a les fameux getters/setters: getHeight et setHeight qui donnent l’accès totale à notre propriété ???
C’est encore plus dangereux si height est un pointeur (de type List, Set, …) parce que dans ce cas le getter seul suffit pour exposer la propriété au public (si on n’utilise pas le “defensive copy”, et c’est souvent le cas avec la génération automatique de getters/setters)
Pire encore, cette pratique est aussi un signe de mauvais design car elle transgresse les principes de la programmation orienté-objet (encapsulation) et rend le programme plus procédural que objet.
Avec 2 ans dans l’environnement professionnel, j’ai vu plein de code comme au-dessus. Qui a écrit “bêtement” les getters/setters comme ça ? Personne! Avec les IDEs modernes, les gens apprennent vite l’habitude de générer les getters/setters et comme c’est trop facile à faire, on trouve partout les getters/setters qui ne sont jamais vraiment utilisés. Ils sont juste là, comme une bombe à retardement, ne font rien mais attendent le jour où on doit faire des changements au code pour exploser.
Pour savoir pourquoi les getters/setters sont mauvais:
Why getter and setter methods are evil
Un excellent article sur les getters et le design de Martin Fowler:
GetterEradicator