|
|
Re: JavaSpaces: Data, Decoupling, and Iteration
|
Posted: Oct 10, 2002 10:55 PM
|
|
> 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.
|
|
Previous Topic
