> Where do I draw that line? For example, I've written
> many methods that only need a String as parameter,
> e.g. "user name". I'm always in a dilema whether to
> make the parameter a simple String or the whole User
> object. The latter option appealedd both because it
> seemed more "Object-Oriented", and the signature
> seems more telling even if poor parameter names are
> chosen - that String could be anything but User is
> more clear. However, this could place more burden on
> clients and limit usability (some contexts might not
> have the whole User object). What if we change the
> example method to need 2 properties of a an object,
> or 5? What then? My guess (as I am writing this) is
> to decompose the the larger object into finer ones
> and have only the appropriate required finer object
> as parameter to the method. Any thoughts?

This is a good question. I was just recently debating with Matt Gerrans over whether a particular method parameter should be a String or a File. Actually, I think I had originally put a File in there and Matt was questioning my choice. We settled on String, because we figured it was simpler and more likely the form the user already had.

I wouldn't consider a User (or File) more "object-oriented" than String. A String is an object too.

One question I'd ask, now that I've heard Ken Arnold on the subject, is: "What form does the user most likely already have in hand?" That form would be the easiest for the user. But you usually can't be certain of the answer. Matt and I weren't sure that users would have Strings more often than File objects in hand, but we thought that was more likely. Ken talks about this question in Part I of his interview:

http://www.artima.com/intv/perfect.html

Another kind of value a more specific type may provide is making sure the data is correct. For example, a URL object, if it is not null, by definition represents a valid URL string, which can be retrieved via the toString or toExternalForm methods. Using URL in a method parameter helps users prevent mistakes, because they can't send you an invalid URL string (other than null).

The last point you raised reminds me of the advice a software manager once gave me, which was that if a type Zoo contains a Lion, a Tiger, a Bear, and a Zebra, but a method only needs the Zebra, then make the parameter type Zebra. If the method needs both a Lion and a Zebra, then probably have two method parameters, one Lion and one Zebra. But if the method needs three of the four animals, then just send the whole Zoo. At some point, in other words, it becomes clearer and easier to just send the whole Zoo, Even though the method does't actually need all the animals, you also want to keep the number of parameters in the method signature to a reasonable, user-friendly number.

> Although I understand your point of not having an iterator
> implementation in Sun JavaSpace, I always thought Sun
> implementations would offer a reasonable framework for
> "basic operations" with an implementation class offering a
> reasonable service.
> If it's hard for Sun's people to think of a good iterator
> framework, it can be hard for us too ;-) !
> I'm trying to find a simple solution for different
> machines to share a set of objects in a javaspace with an
> effective and elegant algorithm : it's not really a simple
> solution that I've found...
> May be the problem is JavaSpace has not been build to
> share things but to dispatch information.

That's correct.

To share information, you are looking for a clustered in-memory data store, like Tangosol Coherence -- see http://www.tangosol.com/coherence.jsp -- which is based on the JCache API instead of the space API.

Peace,

Cameron Purdy
Tangosol, Inc.