Don't take this the wrong way, I'm not trying to defend my position, I'm just stating the reasons I took for adopting it (that is, I didn't randomly do the stuff I did).
I understand. I take an active interest in coding practices, patterns, anti-patterns and so forth - often when I'm researching something I'll bump into an argument about something like this. I cannot remember where I first came across discussion on this subject, but here are a couple of similar ones.
http://groups.google.com/group/comp.lang.java.help/browse_thread/thread/f8b63fc645c1b487/1d94be050cfc249b
http://tech.puredanger.com/2010/03/31/do-we-want-a-java-util-pair/
http://blog.nfnitloop.com/2011/03/scala-vs-java-anti-pattern.html
The last one may be of particular interest because it is talking about how Scala lets you avoid using Tuple in the first place, which makes me wonder why it has Tuple. (Incidentally a good IDE like IntelliJ makes generating a container class fairly simple, since the getters, setters and contructor can all be automatically generated with a few key presses).
Anyway, the principle here is partially around methods having a strong, single purpose and partially around implicitly providing information on the usage of results. If a method is returning two things, they should be naturally related - a method that resolves a DNS entry may return an ip and a port, which naturally go together as an IPAddress. Otherwise it suggests the method is doing two unrelated things, and it should in fact be two methods. Something returning an AssetManager and a GUIManager might actually be two methods, the first setting up an AssetManager and returning it, the second taking an AssetManager and returning a GUIManager. Or perhaps these classes need to be refactored so that they are more independent.
On using the results, if a method returns a tuple it doesn't really tell you what the result is anymore - you have some object with a couple of things in it, you might know what type they are and if you are lucky they are different types. Sure the doco for the method will say, but that doco is off somewhere different from where the method is being used. The best documentation, the best way to make code understandable, is if it reads as naturally as possible just from using it (I'm still working on this). It also can make code less prone to error as well:
Code:
Tuple<String, Integer> ipAddress = getIpAddress();
new URL("http://" + ipAddress.getSecond() + ":" + ipAddress.getFirst());
vs
Code:
IPAddress ipAddress = getIpAddress();
new URL("http://" + ipAddress.port() + ":" + ipAddress.getIP());
The second form makes it far easier to pick up errors from simple inspection of the code. Better, you are far less likely to make the mistake in the first place.
On a slight tangent, this can also be a problem with method parameters. Something like:
Code:
public Date(int day, int month, int year);
is susceptible to parameters being provided in the wrong order (e.g. "new Date(9, 30, 2013)"). A rather clever way of dealing with this is through marker classes:
Code:
public Date(Day day, Month month, Year year);
Where Day, Month and Year may just wrappers around an int (so you would do "new Date(new Day(3), new Month(10), new Year(2013))", though you can certainly do better) - this allows the compiler to prevent misordering. This can be rather cumbersome in general practice though. Still a useful trick in some cases - I used it for Terasology's Rotation class. At any rate you would have to do something for the date constructor - using an enum for Month perhaps. Or at least have a static constructor method like Date.createDayMonthYear() that clarifies the correct order.
I basically used
Scala's Tuple2 and "ported" it to Java. I find it strange that such a generic class could be considered bad practice, because what you suggest seems to be to create a class "AssetManagerAndGuiManager", and if I'd need to return two values somewhere else, "FooAndBar" (please correct me if I'm wrong). That'd be like creating a class "AssetList" extending ArrayList (or whatever) for when I need a list of assets.
I would say List gives some semantics around its contents (that is, that it is an ordered collection of objects of a given type) . That ordering might be important, but you wouldn't generally expect the first element to be used for one thing, and the second element a completely different thing - they are generally homogenous.
A better argument could be made around Vector3f - we return this for both position and velocity for instance, two things with very different semantics. Indeed, in more a scientific system you these should probably be different types, and interactions between them would be better controlled - position + velocity would not be allowed, first you would need to convert velocity to a displacement by multiplying it by time. We sacrifice that safety for the benefit of simpler, more generic code, and we reap the cost of the errors that result (we also partly just use Vector3f because that is what the physics engine uses and the interop is convenient). That is the same trade off that Tuple2 represents, but given the low instance of methods returning multiple values it is one where I think we can pick the side of safety.
On the style... methods in standard Java simply don't start with underscores. Even if it only needs to be written once, every time someone wants to use the class they'll have to deal with this. getFirst() and getSecond() would be the more natural java method names.
