Pourquoi chaque type d'objet n'est-il pas implicitement sérialisé?
Dans ma compréhension limitée, sont des objets non simplement stockés sur le tas et les pointeurs sur la pile?
Ne devriez-vous pas être capable de les traverser de manière programmatique, de les stocker dans un format universel et de pouvoir les reconstruire de là?
6 Réponses :
Certains objets encapsulent des ressources telles que les pointeurs de fichiers ou les prises de réseau qui ne peuvent pas être désérialisés à l'état où vous étiez lors de la diffusion de l'objet qui les contient.
exemple: vous ne devriez pas désérialiser un
objet qui sert d'authentifié
Connexion de base de données, car pour le faire,
vous auriez besoin de la forme sérialisée pour
contenir un mot de passe en plainte. Cette
ne serait pas une bonne pratique, parce que
quelqu'un pourrait avoir une prise de la sauvegarde
forme sérialisée. Vous n'avez pas non plus
idée quand vous désérialisez que le
Le serveur de base de données est toujours en cours d'exécution, peut
être accessible, l'authentification
Les informations d'identification toujours valables, etc.
Non, car parfois, vous n'avez pas toutes les informations de l'endroit que vous les reconstruisez. N'oubliez pas que vous ne pouvez pas reconstruire l'objet dans le même contexte que lorsque vous l'avez eu; C'est peut-être une machine différente ou même une langue différente.
Même si vous ne considérez que des objets qui n'incluent pas l'état du système d'exploitation, le problème est plus difficile qu'il n'y paraît à première vue. Le graphique peut avoir des cycles. Les entités peuvent être référencées à partir de plusieurs entités de niveau supérieur.
Droite, il peut y avoir des cycles, etc., mais ces problèmes sont résolus. Contrasez-la avec la signification de la séricialisation d'une poignée de fenêtre ou d'une poignée de fichier.
@Steven Sudit: Je les caractériserais comme "connu pour être résoluble" plutôt que "résolu". Il existe des décisions qui doivent être effectuées: des compromis entre combien vous serifiez maintenant et à quel point la structure désérialisée est identique ultérieure. Différents problèmes peuvent appeler à différents choix. Les problèmes ont donc des solutions, mais aucune solution unique ne fera pour tous les cas. C'est ce qui rend le problème difficile.
Le problème est difficile, mais d'autres l'ont déjà résolu pour nous. En .NET, par exemple, il existe un système de sérialisation parfaitement fonctionnel qui gère les cycles sans attelage. Il existe également des solutions comparables dans d'autres plates-formes. Cependant, qu'aucun d'entre eux ne peut jamais faire est de sérialiser des choses comme des poignées. C'est une question plus profonde.
@Steven Sudit: Vous avez peut-être manqué mon point. Voilà Trade offrez-vous de construire un sérialisateur général. C'est bien que les gens .Net ou les racines les ont construits. Mais que si ma situation appelle à un ensemble différent de commerce? Le problème est toujours solvable, mais aucune solution unique n'est toujours applicable.
@DMCKEE: Je pense que nous pouvons parler au-delà des autres, plutôt que de désaccorder. Je ne nie pas qu'il existe des problèmes et des complexités à la sérialisation générale. Mon point était que celles-ci sont, à la fois en tant que principales et pratiques, solvables ou au moins résolvables. D'autre part, il existe des types de ressources que la sérialisation n'est tout simplement pas significative pour cela et cela ne changera jamais jamais. Nous ne pourrons jamais utiliser Hibernate ou XMLSérialiseur ou quoi que ce soit sur une poignée mutex, sa valeur n'a pas de sens lorsque le mutex s'en va.
@StevensUDIT: Le problème est en général insoluble, même si l'on se limite à l'univers des objets gérés. Supposons qu'une classe ait un champ de type objet qui contient une référence à une instance réelle de system.Object [pas un type dérivé]. Un tel champ peut encapsuler des informations en vertu du fait qu'il contient une référence au même objet que d'autres champs quelque part quelque part, mais aucune routine de sérialisation à usage général ne pouvait éventuellement comprendre cela sans pouvoir résoudre le problème d'arrêt.
Techniquement, tout objet dans un espace mémoire peut être sérialisé et persisté à un support durable comme un disque dur. Après la plupart des osés, la mémoire active de la page OSES sur Disk et de nombreux ont également une fonctionnalité de style hibernate. Le problème est l'une des possibilités d'étendue, par exemple: vous créez un objet de chaîne dans votre espace mémoire, c'est à vous de sérialiser et de désérialiser comme vous le voyez. Lorsque vous ouvrez un fichier, le système d'exploitation vous donne une poignée de fichier, mais le système d'exploitation possède toujours le système de fichiers contenant l'objet de fichier réel que vous avez une poignée. Un pilote de système de fichiers d'autre part doit conserver une base de données persistante de poignées de fichier et d'autres métadonnées liées au dossier.
Quelle sens importerait-il à sérialiser un objet contenant une connexion réseau et est responsable de la diffusion de données en continu d'un serveur Web?
Qu'en est-il de la désériorialiser, comment cela fonctionnerait-il? Devrait-il rouvrir la connexion, télécharger le fichier?
Vous avez raison dans vos hypothèses, d'une certaine manière.
Il doit être possible de partitionner l'ensemble de tous les objets du programme en groupes
1) Vous avez des informations complètes qui permettent une déconstruction complète et une reconstruction de l'objet. Les matrices de chiffres ou de chaînes, les structures sont de bons exemples.
2) Vous avez des informations de construction. Vous pouvez reconstruire l'objet en appelant le code externe. Un fichier est un bon exemple, mais il faut que votre programme ait une abstraction de fichier qui se souvient des paramètres de construction et d'état. Nous pouvons par exemple enregistrer le chemin du fichier et la position dans le fichier. Cependant, la reconstruction pourrait échouer. (Par exemple, le fichier a été supprimé ou modifié)
3) Vous n'avez aucune information de construction, l'objet a été reçu de manière aléatoire.
ici, pour pouvoir sérialiser complètement les objets, nous devons aller de 3) à 2) à 1). Les objets en 3) peuvent être des attributs d'un objet de type 2) et peuvent être récupérés en reconstruisant avec succès un objet de type 2).
Un objet de type 2) Cependant, doit être reconstruit en sérialisant simplement des informations de construction, qui doivent être de type 1), par exemple des numéros et des chaînes, des données vraies.
Tout ce schéma semble coûteux car si nous voulons reconstruire l'état de l'ensemble du programme, nous devons travailler avec des abstractions qui encapsulent des objets de type 2). Et nous devons savoir ce que nous faisons lorsqu'un objet ne peut pas être reconstruit. De plus, nous devons nous assurer que nous ne mélangions pas d'objets de ces types, que nous ne mélangions pas d'objets de type 3 ou 2 où nous nous attendons à percevoir des objets de type 1.
Je me demandais juste en général .. :-)