Comme nous savons que le motif de memento est sans violer l'encapsulation, capturer et extérioriser l'état interne d'un objet et peut être récupéré ultérieurement sans connaissance de l'état d'origine.
Ma question vient ici comment Java.IO.Sérialisable vient sous ce motif, car lorsque nous sommes
3 Réponses :
le Article Wikipedia sur le modèle de Memento ne mentionne rien de l'encapsulation, dans Fait, l'exemple étant donné qu'il capture exactement l'état détenu dans une variable privée dans un souvenir.
Encapsulation ('A L'état interne d'un objet pourrait cependant avoir été déterminé par une entrée externe telle que le contenu d'une chaîne dépend du fichier qu'il a été lu ou quelles données ont été reçues du réseau. L'état de la case à cocher dépend de la question de savoir si l'utilisateur l'a vérifié ou non alors que le champ correspondant de la classe peut avoir un accès privé et que l'État ne peut être en lecture seule pour d'autres classes.
Protéger les champs en les mettant sous un accès privé est destiné à aider le développeur à maintenir les états d'objets dans un état cohérent, c'est-à-dire éviter que les champs soient définis sur un état incohérent du code à l'extérieur de cette classe (par exemple, si la valeur du champ Cela n'a rien à voir avec la «confidentialité» en ce sens que ces données sont considérées comme A dépend de la valeur du champ B ).
+1 à cela. L'encapsulation signifie qu'une classe n'autorise pas d'autres entités du programme d'accéder et de modifier directement les données / méthodes. Si l'encapsulation signifiait une opacité totale et non partielle, alors quelle classe qui enregistre-t-elle ses membres de données privées dans un fichier texte? Un violateur de principes d'encapsulation? En fait, cela signifierait que tous les systèmes de gestion de la base de données orientés objet violent l'encapsulation. Et cela gênerait O-O Gourous beaucoup trop :-)
de l'article d'encapsulation de Wikipedia: dans une encapsulation de langage de programmation est utilisée se référer à l'une des deux notions associées mais distinctes, et parfois à la combinaison de ceux-ci:
de l'article d'objet opaque: Le contenu sont opaques et ne sont généralement pas interprétés tant que le destinataire passe Le cookie (ou dans notre cause, l'objet) les données retour à l'expéditeur ou peut-être un autre programme ultérieurement.
L'encapsulation n'est pas cassée. Le motif de Memento empêche l'objet de gardien de modifier l'objet Memento, de sorte que l'expéditeur puisse le prendre pour la restauration ou d'autres utilitaires.
Ma compréhension est que le modèle de Memento ne spécifie rien sur le format / opacité / sécurité du miment / jeton lui-même. Le format du Memento (lisible à l'homme, entièrement crypté, ou n'importe où entre les deux), n'est pas pertinent pour le motif lui-même.
Je dirais que la sérialisation (XML ou Binary) est un bon exemple de mise en oeuvre de Memento. Le fait qu'il expose des internes d'objet peut signifier que ce n'est pas la meilleure mise en œuvre de votre projet. Cependant, il s'agit toujours d'une mise en œuvre valable du motif. :)
Article Wikipedia sur le modèle de Miment n'a aucune occurrence de
encapsulation .@Andre, veuillez vous référer ci-dessous lien. Javacamp.org/designPattern
Un autre lien pour votre référence. Sourciakaking.com/design_patterns/Memento
L'article Javacamp.org sur Memento mentionne explicitement «utilisé dans la transaction de base de données», qui est généralement équivalent à la sérialisation, comme cas d'utilisation.
Le livre Gof mentionne explicitement l'encapsulation. Il va expliquer que le souvenir devrait être "opaque" à tout le monde, mais la classe d'origine.
@ ADVS89, cela signifie-t-il qu'il ne devrait pas être utilisé pour la sérialisation, s'il est sérialisé par une classe différente (par exemple un cadre XML)?
Ce n'est pas Stackoverflow.com/questions/14076772/ ...