The Artima Developer Community
Sponsored Link

JavaSpaces: Data, Decoupling, and Iteration
A Conversation with Ken Arnold, Part V
by Bill Venners
October 7, 2002

<<  Page 2 of 5  >>

Advertisement

Asking Questions of a Space

Bill Venners: How is it that I can take an entry template and populate it with a few objects, and that forms a question? How do you get from bits and bytes to high-level conceptual questions?

Ken Arnold: When you query a JavaSpace with an entry containing some filled-in fields, you are saying, "These are the pieces I care about, please fill in the rest." When you write an entry, each field is serialized separately. When you do a read or take with an entry template, each field that you specify is serialized separately. The JavaSpace compares the template fields with stored entries. For each field in the entry, if something is specified in the template, the space compares the fields' serialized forms. The space returns the first stored entry it finds in which all fields specified in the template match the corresponding field in the entry.

Serialization and Private Data

Bill Venners: Somebody once told me he didn't like serialization because it breaks encapsulation and you can see the private data.

Ken Arnold: I think he misunderstood the purpose of private data. Most private data doesn't need to be private for you to hide it from other people because those people should never know about it. Most private data needs to be private because if you let people touch it, they will screw around with it. They'll think they know the right thing to do with the data. Private data is a way of protecting yourself to allow future change. What if somebody serializes an object, plays with the resulting bits, and then deserializes the object to get another object? That is like saying, objects in C++ don't matter because somebody can put a pointer to your private data and muck with it. Although in some abstract logical sense that is true, it is not really the point.

The real point of private data is that you can prevent those people who are not trying to screw you over, but who are just trying to know too much, from knowing too much. If someone goes to that much trouble to interfere with your objects' internals, you should ignore them. Because the value of private data is that you can release a second version and all the existing client code should work because it doesn't rely on internal implementation details.

Say you change the internal structure in your product's second version. If somebody's code breaks because the code has serialized objects—because the person messed with the private stuff and then reserialized it—I don't know how sympathetic you are likely to be. It seems like that person has stepped outside the bounds and got what he or she deserved. So few private things need to be private to be secret. Most of them just need to be private as a language-enforced way of saying hands off.

<<  Page 2 of 5  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us