Синтаксис Java: ярлыки в объявлениях методов?

Question

Быстрый псевдоэстетический вопрос:

Для объявлений полей допускается следующее:

int i, j, k;

предоставление трех переменных для целых чисел. Существует ли что-нибудь подобное для объявлений методов, ala:

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

чтобы доступность метода, тип возвращаемого значения и т. Д. Не задавались избыточно? Я могу представить себе некоторые случаи, когда такой синтаксис может показаться действительно полезным (например, методы с разрешенным набором наборов аргументов), поэтому я надеюсь, что он где-то там есть. Я пробовал выше, и это не похоже на работу.

РЕДАКТИРОВАТЬ: относительно вопроса о потребностях KLE, нет требований, это больше о потребностях. Самое неприятное, с чем я сталкиваюсь, это то, что у меня есть класс алгоритмов, которые являются статическими (и должны быть статическими, поскольку они не зависят ни от чего, кроме своих аргументов), но принимают общий аргумент с некоторыми ограничениями. Ограничения одинаковы для каждого метода, и на самом деле код требует повторения их для каждого метода, но включение их в определение класса (т. Е. public class Foo<U extends Bar>), по-видимому, не позволяет сделать методы статичными.

ТАКЖЕ: Кто-нибудь может уточнить, почему использование совместного использования полей декларация считается плохой практикой? Я думаю, что могу оценить эту перспективу в области коммерческих приложений, но это кажется немного странным в областях научных приложений - разделение типов типов кажется очевидным и простым средством указания, когда вещи должны быть такими же.

Answer 1

Нет, он не существует, и нет, вы также не должны делать это для переменных. Причина: ремонтопригодность, читабельность.

Answer 2

Это считается плохой формой для полей, особенно если используются дженерики. Рассмотрим это (случай из реальной жизни) предварительного общего кода:

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

Теперь a и b имели разное содержимое (их общие типы были бы разными). Это был код Java 1.3 / 1.4, так что это не имело значения. Но теперь, когда мне нужно добавить дженерики, их нужно разделить, и это станет более сложным изменением. Объявление int i, j; вероятно, не существовало бы, если бы не тот факт, что в C / C ++ они есть.

Так что для ваших деклараций методов, конечно, это экономит некоторый шаблон, но в ущерб читаемости и ремонтопригодности. Удобочитаемость в том смысле, что объявление может находиться на расстоянии десятков или сотен строк от остальной части метода. Ремонтопригодность с точки зрения того, что если один из этих методов в середине этой цепочки должен был изменить свой общий тип? Теперь у вас есть целая куча кода, который нужно перемещать, и вы должны правильно расставить запятые.

Теперь это не самая большая сделка, особенно с современной IDE, но суть в том, что Java просто не является кратким языком и ценит выразительность и ясность по сравнению с кратким выражением.

В некоторых случаях это вредит DRY, но в этом случае тот факт, что эти методы имеют одинаковый тип возвращаемого значения, просто случайен, и повторное объявление их не является истинным повторением.

В любом случае, расширение макроса, во всяком случае, было бы более подходящим способом решения этой проблемы (не то, что Java получит это в ближайшее время).

Answer 3

Совместное использование объявлений считается плохой практикой, поскольку легко пропустить переменную в списке; с одним объявлением на строку, глаз сканирует вниз, без необходимости останавливаться и исследовать некоторые строки больше, чем другие. Другая причина заключается в том, что он поощряет людей объявлять все свои переменные в начале метода / класса, а не объявлять их поздно, чтобы помочь GC.

Answer 4

Это считается плохой практикой для полей, вы не найдете его для методов.

---

Не могли бы вы углубиться в свои нужды, может быть, мы можем предложить хорошую альтернативу? : -)

UPDATE

---

Почему плохая практика - определять несколько переменных в одной строке?
Читаемость действительно хуже.

Определить их по отдельности не составляет особого труда, это очень быстро в IDE с завершением и становится стандартом. Со стандартом все начнут зарабатывать много времени.

Кроме того, определение их в одной строке усложняет изменение некоторых из них за одну секунду! Как комментировать один ...

Кроме того, определение их в одной строке означает, что вы не можете дать им Javadoc (или другой комментарий) ... Вы теряете возможности ...

---

Об алгоритмах , которые являются статическими , потому что они не зависят ни от чего, кроме своих аргументов:

• не дороже иметь их динамические. У вас может быть один экземпляр каждого, если вы хотите избежать накладных расходов на создание объектов (новых) и сборку мусора.
• Со временем и рефакторинг они могут стать связанными с одним из своих аргументов . Таким образом, метод может перейти к этому классу и стать идеальным из OO: методом, который работает с данными того же класса .
• У нас даже есть шаблоны по этому поводу, например шаблон Command, где обработка фиксируется в объекте. Множество хороших вещей можно получить, используя это с умом ...