I do this a lot in my code that works with lots of 2 dimensional coordinates:
int[] getSize() {
int[] res = {gridRows, gridColumns};
return res;
}
I know that I could define a tiny class and get type safety but I haven't because it annoys me to have such a trivial class in it's own little trivial .java file that I have to incorporate in my code.
Do you think this is ugly, bad, or evil? Or do you do it too?
If there's a concept in your project that you want to encapsulate, for instance, of those two ints are coordinates, there's nothing wrong with having a Class for them. In my opinion that's alot cleaner then forcing everyone to create an array, etc.
For instance, is someone else is developing in the same project and calls your method, do you think it's clearer for them to get a int array with two positions, or an object called Coordinates?
Furthermore, you might want to implement things like comparing coordinates, which could be encapsulated in a correct OO fashion if you use a Class. (Please do remember to respect the Object contract if you redefined something like equals).
In this case, you could use Point.
In general, aesthetics aside, often there are enough trivial helper methods related to something like this that it makes sense to make a class for it to hold them, rather than have that logic scattered all over. Sometimes even just having a good toString() for debugging and logging is reason enough.
Where very high performance is a concern, make high-traffic trivial helper methods final, so that they can be inlined.
Where the only things the potential members have in common is that they're returned by a function, definitely make a class if you can see a future where they have more in common.
In some cases, consider returning void, and passing in a larger-scoped context object of some kind on which the method can set the return values. This should be used with great caution - it can easily cause coupling creep.
you can define it as a nested static class
not to mention that the class would allow much more (for example define the operations on the 2D coordinates in 1 spot, put them in a set (equals doesn't work like that on arrays))
You could create an inner class to hold the return values of the method. This has the advantage of not requiring a new .java file:
public class Parent{
public Size getSize() {
return new Size(gridRows, gridColumns);
}
public static class Size{
//...
}
}
Parent parent = new Parent();
Parent.Size size = parent.getSize();
Defining the class as "static" basically means that it can be treated just like a normal class (except you have to use Parent.Size instead of Size). If the class is not "static", then you can't create a new instance of it without having an instance of the outter class.
Unfortunately in java this is really the best way to return multiple values. I usually use either Arrays or Lists. I don't necessarily think it's "bad form", per se, to create a class for it, but it is unnecessary.
Given that Java can't return multiple values from methods, what you're doing is about the only choice for returning multiple values of the same type . If the values are from different types, you'll have to write a small class (a value object of sorts) for encapsulating the return values.
Yet another, even ugliest option, would be to pass arrays as parameters and leave there the return values - a hack for simulating pass-by-reference in Java. Very discouraged.
