De ce que je me rappelle de mes cours d'objet a la fac, en gros, on a t'apprends "un objet, c'est comme un struct c, sauf qu'a la place de definir les function a part, tu les mets a cote de ta struct. Ah, et pis on peut heriter en objet, ca c'est bien." Du coup les etudiants apprennent a heriter comme des porcs et paf. Ca aide pas :)
Un des gros problemes c'est que la plupart des devs ne savent pas encapsuler. Ca se limite generalement a ce qu'on leur a appris a l'ecole, a savoir "rendre les champs prives et mettre des getters/setter publics dessus".
Je passe mon temps a batailler pour convaincre qu'un code du genre:
Pourquoi? Tout passe par bar. La logique appartient a bar. Ce code est un pur code c. Les objets sont des structs et la methode est une function C qui manipule ces structs. Et pour beaucoup, ca c'est du code objet (certains diraient meme de qualite).
Les concepts de base d'encapsulation genre un root aggregate qui s'occupe d'implementer les regles de manipulations d'une "liste" plutot que d'exposer au monde entier les regles de manipulation de la dite liste sont inconnus de beaucoup. Et pourtant, ca doit etre le pattern le plus utile en development "entreprise". C'est extremement rare de devoir manipuler directement une liste qui n'appartient pas a l'objet courant, et pourtant je vois ca pourtant dans le milieu.
Certains me regardent meme avec des yeux tout ronds quand je suggere que les maps sont le demons et totalement injustifiees dans 90% des cas ou elles sont utilisees et devraient etre remplacees par un root aggregate d'objets haut niveau, bien plus puissant, souple et fiable.
L'autre effet de bord du manque d'encapsulation c'est que le code devient illisible et masque toute la logique metier. 99 things every developer should know en montre un exemple du genre:
Un bug dans la premiere version est dur a detecter a la relecture alors que ca va etre evident dans le deuxieme. Pourquoi? Absence d'encapsulation, la logique de visibilite d'un portfolio est extraite de l'objet et repandue partout dans le code, ce qui a pour effet de bord de ne pas pouvoir utliiser le langage du domaine dans le code. La deuxieme version se lit comme une phrase naturelle ('fin presque...) et ca saybien.
Mais ca va plus loin que ca.
La delegation est laissee de cote face a l'heritage, et ca c'est mal. Bon, a leur decharge, Java supporte mal la delegation.
Et pire encore, l'heritage est sur utilise, pour de mauvaise raisons (les deux plus courantes: heritage pour heriter de donnees au lieu de composer, et heritage simplement pour differencier 2 types d'objets tres proches mais legerement differents). J'ai bosse sur un projet recemment avec une hierarchie de 7 niveaux. L'effet de bord le plus visible c'est qu'on devait utiliser des generics comme des gorets pour s'en sortir, et tout le monde sait que les generics java sont tres tres tres mauvais. Un peu de rafactoring et paf, ca tombe a 2 niveaux, plus de generics, un bon millier de lignes de code purement et simplement supprimees du source. Et accessoirement, un code achement plus simple a lire.
Les pseudos pattenrs a la con J2EE de l'eopque doree du debut des annees 2000 ont fait beaucoup de mal. Surtout quand tout ce dont on avait besoin en fait, c'etait de l'inversion of control. Une fois spring amene dans un projet, n'importe quel projet J2EE se limite a qq patterns usuels sorti du Gang of four et roule ma poule.
MVC a ete particulierement mal interprete dans le monde java, ou la plupart des devs l'ont compris comme "ma vue, c'est ma jsp, mon modele c'est un objet avec attributs et sans aucune methode, et mon controller c'est un foutoir sans nom ou je met des "services" qui implementent la logique metier".
Ca s'appelle l'anemic object anti pattern, c'est un anti pattern, et le resultat direct c'est qu'on fait de la programmation imperative avec des C structs et pas de l'objet.
Alors, certes, le prototypage apporte une certaine souplesse, qui est appreciable dans certains cas, nefaste dans d'autres. Mais ca change pas le fond du probleme, le mec qui ecrit le code ne saura probablement pas s'en servir. Donne du javascript a n'importe quel dev Java de base, il te pondera de la merde pareille.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# Plusieurs
Posté par pasScott pasForstall . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 10.
De ce que je me rappelle de mes cours d'objet a la fac, en gros, on a t'apprends "un objet, c'est comme un struct c, sauf qu'a la place de definir les function a part, tu les mets a cote de ta struct. Ah, et pis on peut heriter en objet, ca c'est bien." Du coup les etudiants apprennent a heriter comme des porcs et paf. Ca aide pas :)
Un des gros problemes c'est que la plupart des devs ne savent pas encapsuler. Ca se limite generalement a ce qu'on leur a appris a l'ecole, a savoir "rendre les champs prives et mettre des getters/setter publics dessus".
Je passe mon temps a batailler pour convaincre qu'un code du genre:
Pourquoi? Tout passe par bar. La logique appartient a bar. Ce code est un pur code c. Les objets sont des structs et la methode est une function C qui manipule ces structs. Et pour beaucoup, ca c'est du code objet (certains diraient meme de qualite).
Les concepts de base d'encapsulation genre un root aggregate qui s'occupe d'implementer les regles de manipulations d'une "liste" plutot que d'exposer au monde entier les regles de manipulation de la dite liste sont inconnus de beaucoup. Et pourtant, ca doit etre le pattern le plus utile en development "entreprise". C'est extremement rare de devoir manipuler directement une liste qui n'appartient pas a l'objet courant, et pourtant je vois ca pourtant dans le milieu.
Certains me regardent meme avec des yeux tout ronds quand je suggere que les maps sont le demons et totalement injustifiees dans 90% des cas ou elles sont utilisees et devraient etre remplacees par un root aggregate d'objets haut niveau, bien plus puissant, souple et fiable.
L'autre effet de bord du manque d'encapsulation c'est que le code devient illisible et masque toute la logique metier. 99 things every developer should know en montre un exemple du genre:
la ou ca devrait etre un :
Un bug dans la premiere version est dur a detecter a la relecture alors que ca va etre evident dans le deuxieme. Pourquoi? Absence d'encapsulation, la logique de visibilite d'un portfolio est extraite de l'objet et repandue partout dans le code, ce qui a pour effet de bord de ne pas pouvoir utliiser le langage du domaine dans le code. La deuxieme version se lit comme une phrase naturelle ('fin presque...) et ca saybien.
Mais ca va plus loin que ca.
La delegation est laissee de cote face a l'heritage, et ca c'est mal. Bon, a leur decharge, Java supporte mal la delegation.
Et pire encore, l'heritage est sur utilise, pour de mauvaise raisons (les deux plus courantes: heritage pour heriter de donnees au lieu de composer, et heritage simplement pour differencier 2 types d'objets tres proches mais legerement differents). J'ai bosse sur un projet recemment avec une hierarchie de 7 niveaux. L'effet de bord le plus visible c'est qu'on devait utiliser des generics comme des gorets pour s'en sortir, et tout le monde sait que les generics java sont tres tres tres mauvais. Un peu de rafactoring et paf, ca tombe a 2 niveaux, plus de generics, un bon millier de lignes de code purement et simplement supprimees du source. Et accessoirement, un code achement plus simple a lire.
Les pseudos pattenrs a la con J2EE de l'eopque doree du debut des annees 2000 ont fait beaucoup de mal. Surtout quand tout ce dont on avait besoin en fait, c'etait de l'inversion of control. Une fois spring amene dans un projet, n'importe quel projet J2EE se limite a qq patterns usuels sorti du Gang of four et roule ma poule.
MVC a ete particulierement mal interprete dans le monde java, ou la plupart des devs l'ont compris comme "ma vue, c'est ma jsp, mon modele c'est un objet avec attributs et sans aucune methode, et mon controller c'est un foutoir sans nom ou je met des "services" qui implementent la logique metier".
Ca s'appelle l'anemic object anti pattern, c'est un anti pattern, et le resultat direct c'est qu'on fait de la programmation imperative avec des C structs et pas de l'objet.
Alors, certes, le prototypage apporte une certaine souplesse, qui est appreciable dans certains cas, nefaste dans d'autres. Mais ca change pas le fond du probleme, le mec qui ecrit le code ne saura probablement pas s'en servir. Donne du javascript a n'importe quel dev Java de base, il te pondera de la merde pareille.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.