Citation : Le getter te donne du contrôle parce qu'il permet d'avoir un membre privé mais tout de même lisiblePerso, je n'aime pas cette façon de voir (c'est peut-être qu'une question de formulation). Pour moi, le getter en lui-même ne fait pas sens s'il laisse transparaitre le fonctionnement interne de la classe (impossible de supprimer l'attribut privé sans modifier le sens, dans la documentation, du getter).
Je sais que "modifier c'est mal", mais modifier le fonctionnement interne (attributs privés par exemple) d'une classe n'est pas censé avoir d'impact sur les codes extérieurs ni sur la documentation publique (celle à destination de ceux qui utilisent la classe et non de ceux qui la maintienne).
Ok pour dire "$humain->getBrain() renvoie le cerveau de l'humain", mais ce n'est pas forcément un attribut de la classe Humain.
Getter/Setter sans autre utilité que définir/renvoyer la variable peuvent faire sens en PHP grâce au type hinting: le setter n'acceptera que des objets d'une interface donnée, alors qu'une propriété publique accepte tout.
L'hyper-abstraction, on appelait cela "l'effet chercheur" à l'ECN ^^ Un code théoriquement parfait mais ingérable humainement (surtout en petit groupe voire seul)... Probablement gérable si on utilise un outil spécial "gestion de projet abstrait à millions de classes".
Après, je pense que l'approche la plus adaptée dans le cas de l'objet, c'est vraiment la vue subjective: essayer d'avoir une vue d'ensemble d'un projet orienté objet me semble insensé.
Cela devrait vraiment ressembler à sac de noeuds vu de l'extérieur, avec des éléments sans "flot principal", qui laisse vraiment émerger de nouvelles possibilités (sinon, c'est du procédural déguisé).
J'aime bien voir l'OO comme le Web: une toile, avec des noeuds (les sites = les classes), que l'on peut modifier/ajouter/enlever indépendamment, sans demander à un contrôleur "maître", les interconnecter et oublier toute notion de "flot principal" pour ne plus voir que qu'un objet à la fois avec son environnement extérieur (les autres classes) et sa composition interne.
Mais bon, c'est dur d'avoir une approche type "je fais un projet sans le maîtriser entièrement"...
Question bonus:
Je préfère ceci:
Code :
size = allMovies.size()
myMovie = new Movie[size]
allMoviesArray = allMovies.toArray(myMovie)
return (Movie[]) allMoviesArray;à cela:
Code :
return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);car chaque ligne est alors élémentaire (une classe ne gère qu'un truc, une méthode ne fait qu'une chose, une ligne n'exécute qu'une seule action), d'autant plus qu'en cas de changement de source (exemple: size vient maintenant de la méthode .length() ou même d'un paramètre), la modification de code est simplifiée (une ligne à changer au lieu de fouiller le contenu d'une ligne).
Et vous, que préférez-vous?