Re: Java type-casting -- Q3
On Sep 28, 9:30 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Sun, 27 Sep 2009 22:19:15 -0700, grz01 <gr...@spray.se> wrote:
On 28 Sep, 06:53, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com> wrote:
You're not nearly lazy enough if you're willing to write code that you=
have to puzzle over later to figure out its structure.
Pete
Well, the day I need to sit "puzzle" over the type Pair<A,B>
its probably time to retire :)
Ah, well...maybe we can simplify your life quite a bit then.
Here, check this out:
Pair<Integer, String> getData();
Now, tell me everything there is to know about the data being returned by=
the method. What, exactly, will I find there? How are the Integer a=
nd
String related? What do the Integer and String represent? Why do th=
ey
belong together?
The fact is, you can't answer those questions. The name of the type is=
n't
informative at all.
Enjoy your retirement!
Pete
Well, I see what you mean :)
I would rather offer a method, for example.
Pair<Integer, String> getAgeAndName() {...};
The caller might then say:
Pair<Integer,String> ageAndName = getAgeAndName();
Integer age = ageAndName.getFirst();
String name = ageAndName.getSecond();
No less, no more informative, that I can see, than first defining
this:
class AgeAndName(){
// ... here repeat yourself til you die by defining
// getAge(), setAge, getName(), and setName()
}
and then defining method:
AgeAndName getAgeAndName(){...};
where the caller might then say:
AgeAndName ageAndName = getAgeAndName();
Integer age = ageAndName.getAge();
String name = ageAndName.getName();
I just dont see the obvious advantage in bloating your code with silly
JavaBeans like this.
I do see the several advantages in not repeating yourself
unnecessarily.