L'auteur remet en question l'application des principes de conception orientés objet, notamment l'encapsulation, dans des scénarios complexes tels que la duplication et la versionning d'objets. Ils reconnaissent l'importance de conserver les données avec le comportement, mais ont du mal à décider quel objet devrait savoir comment exécuter certaines actions. L'auteur fournit un exemple de modèle Parent-Enfant où le Parent devrait orchestrer la duplication des enregistrements imbriqués. Cela soulève la question de où placer la logique d'orchestration qui s'étend sur plusieurs objets. Trois options sont présentées : utiliser un modèle d'objet orchestrateur ou de service, rendre le racine d'agrégat responsable, ou déléguer la duplication à l'objet imbriqué. Chaque option a des avantages et des inconvénients, tels que garder la logique d'orchestration hors des modèles de domaine versus accumuler la logique de coordination dans la racine d'agrégat. L'auteur conclut que l'encapsulation est précieuse, mais les comportements contextuels comme la versionning et la duplication ne doivent pas toujours être inclus dans les objets de domaine. Ces comportements sont temporaires, transversaux et peuvent nécessiter des connaissances que l'objet ne devrait pas avoir. La solution réside dans la réforme de ce que le contexte et l'objet sont les plus appropriés pour encapsuler. Cette approche reconnaît que les entités de domaine modélisent l'état et les invariants, mais pas tous les flux de procédure, et n'est pas une trahison des principes de conception orientés objet.
dev.to
What happens when OOP meets Real World™
