Et même si on ne parle pas du côté testable du code, les dépendances d'injection c'est utile dans la vie de tous les jours.
Si quelqu'un veut utiliser ta Bibliothèque il est obligé d'utiliser ton Storage, tu as pu choisir MySQL, des fichiers ou autre.
Si il veut autre chose il ne peut pas, il doit patcher ta Bibliothèque et à chaque mise à jour il doit la repatcher de nouveau.
Le truc super chiant au possible.
Moi si il veut un Storage sur le cloud avec Amazon, pas de soucis, il construit sa classe Storage qui respect le trait StorageLibrary, il l'injecte à la construction de la Bibliothèque et hop c'est terminé.
Par Reflection je peux récupérer toutes les données de ta classe que je veux et que tu cherches à cacher et m'empêcher de voir et je peux même modifier les propriétés en protected/private.
Si une Bibliothèque gère un pack de livre, un ensemble de livre. Elle va forcément avoir une liste de livre.
Pas une liste de titre, de contenu, d'auteurs, etc. Ca n'est pas question de point de vue, c'est question de programmation objet.
Si ta Bibliothèque n'a pas de liste de livre, tu décides de stocker les données en procédurale et pas en objet.
C'est un choix, mais tu fais à la fois de la POO et de la procédurale de façon... Inapproprié.
En quoi ça te gêne la fuite d'information ?
C'est pas une fuite, une fuite c'est quand ça arrive à l'utilisateur, pas au programmeur, pas au programme.
Tu n'accèdes pas à la propriété privé tu accèdes à increment qui est une méthode publique qui choisit comment modifier la valeur privé.
Que tu ne sois pas d'accord quand je dis que ta Bibliothèque n'est pas Single Responsability, si tu veux, mais tu te trompes.
Gérer une Bibliothèque : 1 responsabilité
Stocker la Bibliothèque : 1 autre responsabilité
Traduire la Bibliothèque : 1 autre responsabilité
Si quelqu'un veut utiliser ta Bibliothèque il est obligé d'utiliser ton Storage, tu as pu choisir MySQL, des fichiers ou autre.
Si il veut autre chose il ne peut pas, il doit patcher ta Bibliothèque et à chaque mise à jour il doit la repatcher de nouveau.
Le truc super chiant au possible.
Moi si il veut un Storage sur le cloud avec Amazon, pas de soucis, il construit sa classe Storage qui respect le trait StorageLibrary, il l'injecte à la construction de la Bibliothèque et hop c'est terminé.
Par Reflection je peux récupérer toutes les données de ta classe que je veux et que tu cherches à cacher et m'empêcher de voir et je peux même modifier les propriétés en protected/private.
Si une Bibliothèque gère un pack de livre, un ensemble de livre. Elle va forcément avoir une liste de livre.
Pas une liste de titre, de contenu, d'auteurs, etc. Ca n'est pas question de point de vue, c'est question de programmation objet.
Si ta Bibliothèque n'a pas de liste de livre, tu décides de stocker les données en procédurale et pas en objet.
C'est un choix, mais tu fais à la fois de la POO et de la procédurale de façon... Inapproprié.
En quoi ça te gêne la fuite d'information ?
C'est pas une fuite, une fuite c'est quand ça arrive à l'utilisateur, pas au programmeur, pas au programme.
Tu n'accèdes pas à la propriété privé tu accèdes à increment qui est une méthode publique qui choisit comment modifier la valeur privé.
Que tu ne sois pas d'accord quand je dis que ta Bibliothèque n'est pas Single Responsability, si tu veux, mais tu te trompes.
Gérer une Bibliothèque : 1 responsabilité
Stocker la Bibliothèque : 1 autre responsabilité
Traduire la Bibliothèque : 1 autre responsabilité