L'idee c'est qu'un ensemble d'objets est lie ensemble par le root aggregate, qui est responsable de fournir des methodes d'acces aux dits objets et maintenir la cohesion du tout en forcant toute manipulation de l'ensemble a passer par lui. T'as un point central d'acces a ces objets, ce qui concentre la logique au bon endroit et permet d'implementer la logique metier proprement.
T'as bien evidemment toujours le droit de recuperer un seul objet de l'ensemble et le manipuler comme tu veux, mais tu dois le recuperer via le root. Souvent t'as un backpointer vers le parent, qui te permet d'implementer a moindre cout des gardes fous ou d'acceder aux freres de l'objet en question.
L'interet immediat c'est que ca te garantit que ton graphe d'objet est toujours consistant (au sens anglais, le francais me vient pas a l'esprit, desole), l'autre interet c'est la lisibilite du code, sans compter les trucs habituels, encapsulation donc refactoring facilite, reutilisablite du code etc.
Pour les maps le gros problemes c'est que c'est un gros sac offrant tres peu de souplesse niveau manipulation, sans compter que ca retire beaucoup de semantique.
Transforme ca en une liste d'objets liant la cle a la valeur (ce qui te permet en cado bonux de rajouter de la logique sur cette association), le tout lie ensemble par un root aggregate, tu gagnes enormement:
- clarte, tu as un objet qui a une semantique claire et pas un sac fourre tout
- lisibilite, les objets exterieurs accedent a tout ce beau monde via des methodes au nom explicite et a la semantique claire (cf l'exemple du portefeuille d'action plus haut ou la premiere version est incomprehensible face a la deuxieme qui est clair comme de l'eau de roche)
- souplesse, tu peux aisement rajouter/supprimer des attributs sans peter tout ton code
- puissance tu peux maintenant tres aisement ajouter des methodes donnant un acces plus fin aux elements de la map
Et en plus t'as transforme une map qui est une structure relativement complexe en liste qui est achement plus simple a manipuler et serialiser (tous les lanagages n'ont pas de maps supportant un objet enmcle, par exemple, ou pas simplement).
Un livre de chevet indispensable a tout dev objet: domain driven design d'eric evans. Ca changera probablement la vision que les sceptiques ont de l'objet. Et bien evidemment le gang of four.
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.
[^] # Re: Plusieurs
Posté par pasScott pasForstall . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 3.
L'idee c'est qu'un ensemble d'objets est lie ensemble par le root aggregate, qui est responsable de fournir des methodes d'acces aux dits objets et maintenir la cohesion du tout en forcant toute manipulation de l'ensemble a passer par lui. T'as un point central d'acces a ces objets, ce qui concentre la logique au bon endroit et permet d'implementer la logique metier proprement.
T'as bien evidemment toujours le droit de recuperer un seul objet de l'ensemble et le manipuler comme tu veux, mais tu dois le recuperer via le root. Souvent t'as un backpointer vers le parent, qui te permet d'implementer a moindre cout des gardes fous ou d'acceder aux freres de l'objet en question.
L'interet immediat c'est que ca te garantit que ton graphe d'objet est toujours consistant (au sens anglais, le francais me vient pas a l'esprit, desole), l'autre interet c'est la lisibilite du code, sans compter les trucs habituels, encapsulation donc refactoring facilite, reutilisablite du code etc.
Pour les maps le gros problemes c'est que c'est un gros sac offrant tres peu de souplesse niveau manipulation, sans compter que ca retire beaucoup de semantique.
Transforme ca en une liste d'objets liant la cle a la valeur (ce qui te permet en cado bonux de rajouter de la logique sur cette association), le tout lie ensemble par un root aggregate, tu gagnes enormement:
- clarte, tu as un objet qui a une semantique claire et pas un sac fourre tout
- lisibilite, les objets exterieurs accedent a tout ce beau monde via des methodes au nom explicite et a la semantique claire (cf l'exemple du portefeuille d'action plus haut ou la premiere version est incomprehensible face a la deuxieme qui est clair comme de l'eau de roche)
- souplesse, tu peux aisement rajouter/supprimer des attributs sans peter tout ton code
- puissance tu peux maintenant tres aisement ajouter des methodes donnant un acces plus fin aux elements de la map
Et en plus t'as transforme une map qui est une structure relativement complexe en liste qui est achement plus simple a manipuler et serialiser (tous les lanagages n'ont pas de maps supportant un objet enmcle, par exemple, ou pas simplement).
Un livre de chevet indispensable a tout dev objet: domain driven design d'eric evans. Ca changera probablement la vision que les sceptiques ont de l'objet. Et bien evidemment le gang of four.
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.