Use Objects To Return Multiple Values

From code floating around the lab:

	 public class Map {

	 ... lots of public variable declarations including

	 public double lastDistance;  // last dist for closestLink

	 .... and then a function which needs to return two pieces of data 

	 public MapLink? closestLink(Pt p) {

		....
		return c;	// recall: lastDistance also meaningful;
				// ... wishing for Lisp's multiple-value returns
	}

	public double getLastDistance() {
		return lastDistance;
	}

	MapLink? closestLink = map.closestLink(p);
	double distance = map.getLastDistance();

More precisely: If you're in a situation where the logical return value consists of two associated pieces of information, define a new object that holds both and return it. Don't structure your API so that arguments are sent in one call and a second call retrieves the return value.

WilliamGrosso

(I made the public instance variables private because I though the lack of accessors confused the main point -- DaveHarris.)

"Now the sole point of this class is to encapsulate some geometric calculations." Fine. In other words, it's an example of MethodObject. If there is a mistake, it is in combining two MethodObject(s) into a single class. Maybe you need something like:

	class LinkFinder? {
		private Map toSearch;
		private Point toSearchFor;
		private MapLink? found;
		private double lastDistance;
		// ...
	}

	LinkFinder? finder = new Finder( map );
	finder.setTarget( pointToFind );
	finder.find();
	MapLink? closest = finder.getFoundLink();
	double distance = finder.getDistance();

(Consider also the Command/Function distinction promoted by Eiffel.) -- DaveHarris

What I said was:

client messages the map and gets back an object encapsulating the results.

what you said was

client creates an object to encapsulate the results and tells it to go acquire some state.

Which seems, more or less, to be the similar to what I mentioned (we're both avoiding messaging the map twice to get the two return values). But there's also something trickily different here and I can't quite put my finger on it.

When would I do one, as opposed to the other ?

WilliamGrosso

Still confused. I'm thinking of ValueObject. Aren't ValueObjects frequently created by a different object and passed around ? Isn't that part of the point of a ValueObject (e.g. a ValueObject is a piece of information along with things you can ask it. It can come into existence in many separate ways and that behavior is frequently partitioned out into either a factory or as part of other objects which have more context-sensitive state) ?

And if the above question about ValueObjects is reasonable, where do we draw the line and switch over to more "intelligent" objects ?

WilliamGrosso

Clearly it can be done either way ... I seem to prefer the second ... maybe I'm not sure why, but someone can tell me. --rj

        MapLocation? location = map.locationAt (new Point (3,4));
        MapLink? link = location.findClosestLink ();
        int distance = location.distanceFrom (link).

In general, I like UseObjectsToReturnMultipleValues. It is an instance of ResultObject. But, I would not use it here.

-- MichaelFeathers

LinkFinder? reminds me of something that I try to avoid. I was actually thinking of writing up the idea on Wiki a while back, but I never got around to it.

LinkFinder? (and many MethodObject implementations) allow "state orphanage." You can set the target point for a LinkFinder? and then pass it to someone. They may look at the result of the getDistance call and get the sense that it is the distance for the current target, not the one that was set prior to the last find.

I tend to think that methods should be understood in terms of the current state of the reciever.. the "self." getDistance () should return the distance of reciever. setTarget () should set the target of reciever. If you ask "what is the target point of reciever?" and "what is the distance of reciever?" and someone has called setTarget () without calling find (), you can get misleading information.

What do you all think?

-- MichaelFeathers

Sometimes you have too many arguments for the single-step constructor to be convenient. Then you may have a 2-phase object: it's mutable during the set-up processes, but then becomes immutable once it is complete. Or you have set-once variables. Thus:

	setTarget( Point target ) {
		Assert.assert( this.target == null );
		Assert.assert( target != null );
		this.target = target;
	}

I like your earlier point about caching. The original code could have been written that way, without introducing new objects. Instead of:

	public class Map {
		// ...
		public MapLink? closestLink(Pt p);
		public double getLastDistance();
	}

	public class Map {
		// ...
		public MapLink? closestLink(Pt p);
		public double getDistance(Pt p);
	}

Yes, but isn't there another issue here? What is the "distance" of a map? When we ask for distance, we ought to be asking either a link for its distance from a location, or a location for its distance from a link. Maybe something like: Map.getDistance (Link link, Point point) would work? -- MichaelFeathers

Would you all opt for making a ResultObject here?

-- MichaelFeathers

This page mirrored in JavaIdioms as of April 29, 2006