Je préfère traduire un bouquin correctement même si c'est un peu plus lent, mais bref, continuons.
Non, le principe objet n'est pas de ne rien savoir de ce que fait ton objet. Car à ce compte là, si je ne suis pas foutu de savoir ce qu'il y a dans ma bibliothèque, bah le lui met un joli parpaing autour du cou et je la balance du haut d'un pont.
Non, l'idée ici c'est de ne pas savoir comment fait l'objet pour faire ce qu'il fait. Mais on veut quand même récupérer des bouquins et en déposer.
Avec ta technique, il faudra ajouter des méthodes à la bibliothèque à chaque fois qu'une nouvelle appli voudra s'interfacer avec.
Bon et puis promouvoir le tout objet 'pur' pour ensuite se targuer d'utiliser des types simples je comprends pas la logique. Encore une fois tu mélanges les choses.
Perso mon langage de prédilection (Erlang) ne connaît que les types simples. (Il n'a pas d'objets syntaxiquement). Si je voulais coder une bibliothèque j'utiliserais bien sûr une simple liste, (mais j'aurais également à côté des métadonnées) mais j'autoriserais l'utilisateur à récupérer un bouquin. Ce n'est pas parce que tu laisses quelqu'un itérer sur tous tes livres que tu lui permets pour autant de niquer toutes tes données ou de supprimer des bouquins au hasard.
Regarde une base de données SQL, tu ne sais pas comment sont stockées tes données ni comment sont parsées tes requêtes. Mais la base on s'en fout, ce qui compte ce sont les données. Tu as donc une API complète pour lire les données (SELECT), les modifier (UPDATE), etc.
Mais si tu ne le fais pas correctement, tu plantes. Et si tu n'envoies pas les bonnes infos de connexion, tes droits peuvent être réduits.
Un ORM calé sur cette base te permet à son tour de ne pas gérer les appels à la base et de te concentrer sur les données. Il permet aussi de contrôler la validité des données avant enregistrement, et il te permet d'itérer sur toute une table pour changer les données à ta guise. Il te simplifie simplement le boulot en masquant la façon dont il traite avec la base.
Non, le principe objet n'est pas de ne rien savoir de ce que fait ton objet. Car à ce compte là, si je ne suis pas foutu de savoir ce qu'il y a dans ma bibliothèque, bah le lui met un joli parpaing autour du cou et je la balance du haut d'un pont.
Non, l'idée ici c'est de ne pas savoir comment fait l'objet pour faire ce qu'il fait. Mais on veut quand même récupérer des bouquins et en déposer.
Avec ta technique, il faudra ajouter des méthodes à la bibliothèque à chaque fois qu'une nouvelle appli voudra s'interfacer avec.
Bon et puis promouvoir le tout objet 'pur' pour ensuite se targuer d'utiliser des types simples je comprends pas la logique. Encore une fois tu mélanges les choses.
Perso mon langage de prédilection (Erlang) ne connaît que les types simples. (Il n'a pas d'objets syntaxiquement). Si je voulais coder une bibliothèque j'utiliserais bien sûr une simple liste, (mais j'aurais également à côté des métadonnées) mais j'autoriserais l'utilisateur à récupérer un bouquin. Ce n'est pas parce que tu laisses quelqu'un itérer sur tous tes livres que tu lui permets pour autant de niquer toutes tes données ou de supprimer des bouquins au hasard.
Regarde une base de données SQL, tu ne sais pas comment sont stockées tes données ni comment sont parsées tes requêtes. Mais la base on s'en fout, ce qui compte ce sont les données. Tu as donc une API complète pour lire les données (SELECT), les modifier (UPDATE), etc.
Mais si tu ne le fais pas correctement, tu plantes. Et si tu n'envoies pas les bonnes infos de connexion, tes droits peuvent être réduits.
Un ORM calé sur cette base te permet à son tour de ne pas gérer les appels à la base et de te concentrer sur les données. Il permet aussi de contrôler la validité des données avant enregistrement, et il te permet d'itérer sur toute une table pour changer les données à ta guise. Il te simplifie simplement le boulot en masquant la façon dont il traite avec la base.