Java语法：方法声明中的快捷方式？

Question

Quickie pseudo-aesthetics question:

For field declarations, the following is allowed:

int i, j, k;

providing three variables for integers. Does anything similar exist for method declarations, ala:

public int getI() {/* ... */},
getJ() {/* ... */},
getK() {/* ... */};

so that the method accessibility, return type, etc don't have to be redundantly specified? I can imagine some cases where this sort of syntax would seem really beneficial (eg, methods with an assortment of argument sets allowed), so I'm hoping it's in there somewhere. I've tried the above, and it doesn't seem to work.

EDIT: relative to KLE's question about needs, there isn't a requirement, it's more about wants. The most annoying thing I'm facing is that I have a class of a bunch algorithms that are static (and should be static, as they don't depend on anything but their arguments) but take a generic argument with some restrictions. The restrictions are the same for every method, and it really uglies up the code to have to repeat them for every method, but putting them in the class definition (ie, public class Foo<U extends Bar> ) seems to preclude making the methods static.

ALSO: Can someone elaborate on why using sharing the fields declaration is considered bad practice? I think I can appreciate that perspective in the commercial application realm, but it seems a little strange in the scientific application realm - sharing types fields seems an obvious and simple means of indicating when things should be the same kind of thing.

Answer 1

No, it does not exist, and no, you should not do it for variables either. Reason: Maintainability, readability.

Answer 2

The sharing of declarations is considered bad practice as it's easy to miss a variable in a list; with one-declaration per line the eye scans down, without needing to stop and examine some lines more than others. The other reason is that it encourages people to declare all their variable at the top of the method / class, rather than declaring them late to assist the GC.

Answer 3

It is considered bad form for fields, especially once generics are involved. Consider this (real world case) of pre generic code:

private Map a = new HashMap(), b = new HashMap();

Now a and b had different contents (their generic types would be different). This was java 1.3/1.4 code, so it didn't matter. But now, when I have to add generics, that has to be split apart, and it becomes a more involved change. The declaration of int i, j; would probably not exist if not for the fact that C/C++ has them.

So for your method declarations, sure it saves some boilerplate, but at the sacrifice of readability and maintainability. Readability in the sense that the declaration could be tens or hundreds of lines away from the rest of the method. Maintainability in terms of what if one of those methods in the middle of that chain had to change their generic type? Now you have a whole bunch of code that has to be moved around, and you have to get those commas right.

Now this isn't the biggest deal, especially with a modern IDE, but the bottom line is really is that Java is just not terse language, and it values expressiveness and clarity over concise expression.

In some cases, that hurts DRY, but in this case the fact that these methods have the same return type is simply coincidental and it isn't a true repetition to re-declare them.

Anyway, a macro expansion, if anything, would be a more appropriate way to solve this problem (not that Java is getting that any time soon).

Answer 4

It is seen as a bad practice for fields, you won't find it for methods.

---

Could you dig deeper into your need, maybe we can propose a nice alternative? :-)

UPDATE

---

Why is it a bad practice to define several variables on the same line ?
Readability is really poorer.

Defining them each on its own line is no big deal, it's really fast in an IDE with completion, and it becomes a standard. With a standard in place, everyone will start gaining a lot of time.

Also, defining them on the same line makes it harder to change some of them in one second ! Like commenting one...

Also, defining them on the same line means you cannot give a javadoc (or other comment) for them... You're losing possibilities...

---

About the algorithms being static because they depend on nothing but their arguments :

• It is not more costly to have them dynamic. You can have a single instance of each if you want to avoid the overhead of object creation (new) and garbage collection.
• Over time and refactoring, they might become linked to one of their arguments . So the method could move to that class, and become the ideal of OO : a method that work on data of the same class .
• We even have patterns about this, like the Command pattern, where a processing is captured in an object. Many good things can be gained using this wisely...