CSC/ECE 517 Fall 2009/wiki2 18 i7

From Expertiza_Wiki
Revision as of 03:50, 9 October 2009 by Stphung (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Problem

   When designing a class, it is preferred to have them be immutable because of guaranteed thread safety and consistent object state.  A problem arises in Java when needing a class to be serializable.  (In order to have a class be serializable the Serializable interface must be implemented.  A class that is serializable is one that can be represented on disk as a sequence of bits.)  The reason this is a problem is not on serialization, but rather on deserialization.  During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor.  Java uses this constructor to instantiate the object and populate the fields.  This may not be the case if the superclass is one that is immutable.  The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass.  Serialization proxy pattern aims to solve this problem.

Design

   Instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, the idea behind serialization proxy pattern is that a proxy class is serialized instead of the class.  A proxy class in this context would be a class where enough information is stored to reconstruct the target class.  The design in this case would be on serialization

<Picture>


Implementation Details During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize.

<Picture>

   During deserialization there is a method that Java looks for which is called readResolve.  If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object.  This is where we would read in a proxy object and invoke the constructor for the class we want to reconstruct.<this sentence sucks>

<Picture>

Idiomatic Usage The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it does not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. An example of this structure is the following.

public class B extends A {

   ...
   private static final BSerializationProxy {
       ...
   }

}


References Links Java API Jguru Effective Java