One of the JavaIdioms

Your Java program creates a large number of objects.  These objects themselves contain references to ValueObject''''s as member variables.

                                       * * *

Each Java object requires an extra two or three words of memory to hold the per-object mutex, the reference to the object's Class and other housekeep data used by the runtime.  A ValueObject also requires a reference to be stored in the object that is using it, which requires another word of memory.  So compared to a raw value, a ValueObject has an overhead of three of four words of memory.  This overhead is a problem if you have a very large number of objects -- tens or hundreds of thousands for example. ''(See ObjectOverheadIsRidiculous.)''

'''How can you reduce the overhead of using ValueObject instance variables?'''

                                       * * *

Many Java ValueObject classes provide methods for getting a copy the raw representation of the object.  For example, the Date class provides a getTime method that returns the date as the number of milliseconds since the "epoch", as a long value.

However, raw values don't have any methods, and so are far from convenient.

Therefore:

'''Within an object store the raw representation of a ValueObject property and expose the property as a ValueObject at the object's interface.'''


	* Declare a member variable to store the property as a primitive type.
	* Define public methods whose parameters are of the ValueObject type.
	* Methods that set the value of the property should store the raw value of the ValueObject in the member variable.  (E.g. it should "rip the guts" out of the ValueObject, hence the name of this pattern).
	* Methods that return the value of the property should initialise a ValueObject from the raw value stored in the member variable.


For example:

 class Example
 {
     long _timestamp;
	
     public Date getTimestamp() {
         return new Date( _timestamp );
     }

     public void setTimestamp( Date date ) {
         _timestamp = date.getTime();
     }
 }
 
 
The use of this pattern saves 3 or 4 words per field, which can be important if you are creating thousands of objects.

However:
	* The implementation of the class is made more complex, which will make maintenance harder.
	* Coupling between the class and the class of the ValueObject is increased.
	* Use of the pattern decreases performance, because ValueObject''''s need to be created every time the property is accessed.  This is not much of a problem with modern JVMs, because object allocation requires only a couple of pointer calculations.

In conclusion, only use this pattern if testing has shown that the pattern is 
absolutely necessary.

CrossSection is a related pattern that uses a similar technique to reduce the memory requirements of an array of objects.

----
Two words about the title. ''Eschew Obfuscation!''

I don't understand?  "Eviscerate Parameters" seems a good description for the pattern. What problem do you have with the title?  Could you explain?

I'm not the one who complained, but I have a problem with the title as well.  "Eviscerate", in the context, seems to be an obfuscated (and unnecessarily gory) synonym for "change the form of".  But the real beef I have is that this pattern seems to have little to do with parameters, but instead with instance variables.  A better title might be "Use Primitive Types in Value Objects", or just "Use Primitive Types Instead of Objects" as the context doesn't seem to matter much--the real point of the pattern is that primitive types are more efficient in terms of memory usage than are Object types. --KrisJohnson

How about 'Inline Value Objects' or 'Flatten Value Objects'? -- TomAnderson

----

EviscerateParameters is a specific use of EvisceratedObject''''''s.

See also: FlyweightPattern, for another solution to this problem.