Hej, Richard,

While I fully agree that there is always a case for breaking a rule in
special circumstances (even encapsulation), could I just note a humble
alternative to your approach, though I lack your insight into the
problem?

Firstly, encapsulation can help insulate a class from changes in
another class.

In the solution you have above, I presume that the following line
means: create an instance of TheObjectIwantToFullyLoad and set its
MaxValue accordingly:
"ObjectContainer.Activate(TheObjectIwantToFullyLoad, int.MaxValue)"

If this is the case, then we can consider what happens when
TheObjectIwantToFullyLoad gets a new field variable, let's call it:
String name.

Now, both TheObjectIwantToFullyLoad must change (to add this new
variable) and - more importantly - ObjectContainer must change, as it
must now call:
"ObjectContainer.Activate(TheObjectIwantToFullyLoad, int.MaxValue,
string.name)"

This, we note, is the price of breaking encapsulation.

The question is: could there be a way to respect encapsulation so
that
ObjectContainer isn't affected by any changes to the internals of
TheObjectIwantToFullyLoad?

An answer could be to have TheObjectIwantToFullyLoad (and any
serialisable object) responsible for its own data serialisation. It
could have a method save(BitStream stream). This method is called by
ObjectContainer and it passes in the stream that will be written to
the file system.

It is then up to TheObjectIwantToFullyLoad to convert all its private
data to a bit-stream representation and write this data to the bit-
stream.

The reverse is true when reading a bit-stream from the file system:
TheObjectIwantToFullyLoad itself will be resonsible for inspecting
the  bit-stream and converting it back to an int and a string value.

Now, changes to TheObjectIwantToFullyLoad do not affect the
ObjectContainer.

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html