Существует ли идиома в Java для пустых методов, которые существуют для удовлетворения интерфейса?

В этом конкретном случае вы должны следовать совету wilums2 и расширить MouseAdapter вместо реализации MouseListener. Назначение этих классов адаптеров состоит в том, что вам не нужно предоставлять пустые реализации, когда вы реализуете только некоторые методы интерфейса.

В целом, краткий ответ «нет», стандартного соглашения о том, как документировать пустые методы, не существует, хотя я обычно использую что-то вроде

@Override
void foo() {
  // No implementation necessary
}

В общем, то, о чем вы говорите, является расширением шаблона нулевого объекта. Вы определяете нулевой объект и расширяете его, переопределяя только те методы, которые вам нужны.

В качестве примера способа автоматизации этого в моих аннотациях компонентов JavaDude ( http://code.google.com/p/javadude/wiki/Annotations ) вы можете сделать что-то вроде следующий. [ПРИМЕЧАНИЕ: я бы не рекомендовал делать это для MouseListener, так как MouseAdapter уже существует, и вы можете просто создать его подкласс ... Следующее полезно для других больших интерфейсов, где вы хотите реализовать только несколько методов выбора]

@Bean(nullObjectImplementations = @NullObject(type=MouseListener.class))
public class MyMouseHandler extends MyMouseHandlerGen {
    public void mouseClicked(MouseEvent e) {
        // your handling of a MouseClick
    }
}

Затем вы можете использовать MyMouseHandler для обработки щелчка. =

Примечание: MouseAdapter был действительно неудачным выбором для имени класса в JRE / JDK. Это не экземпляр шаблона GoF Adapter; это действительно реализация объекта MouseListener для Null Object.

Кстати: вы можете поместить @Override в ту же строку, что и объявление метода - для вашего примера вы можете иметь

@Override public void mousePressed(MouseEvent e) { /* not needed */ }
// et al

MouseAdapter отлично подходит для этого конкретного случая, и в целом идиома адаптера. Адаптер имеет пустые реализации всех методов интерфейса, что позволяет вам создавать подклассы и реализовывать только те методы, которые относятся к вашему классу. Адаптер может альтернативно, как предлагает Эндрю Хэйр, генерировать исключение NotImplementedException.

Назначение слушателя - получать уведомления о некоторых событиях. Если интерфейс слушателя содержит больше обратных вызовов методов, чем вам нужно, просто игнорируйте те, которые вам не нужны. В вашем случае MouseAdapter был разработан именно для этой цели. Сделайте not throw UnsupportedOperationException , поскольку вызывающий, скорее всего, не ожидает исключения. Это также, скорее всего, нарушает контракт интерфейса слушателя, поскольку ожидается, что каждый метод будет реализован.

Я делаю это так же, как и вы, если там ничего не остается на одной строке. Может быть, поставьте комментарий поверх большого блока «однострочных фраз о реализации».

Использовать MouseAdapter

Я не думаю, что это особенно важно. По моему личному вкусу, я не люблю видеть закрывающую скобку рядом с открывающей, что дает:

public void mouseEntered(MouseEvent e) {
}

Немного пусто, но нормально. В случае возвращаемого значения мы можем сделать его согласованным, чего нельзя добиться в стиле [] .

Но когда дело доходит до редкого случая в циклах, мне нравится точка с запятой:

// Made up example.
while (++i < len && str.charAt(i) != '\0') {
    ;
}

Что даст:

public void mouseEntered(MouseEvent e) {
    ;
}

В случае предложений catch вам лучше иметь хороший повод в комментарии (возможно, отбросить прерывание).

Думаю, я бы описал это как «безоперационные реализации» или, возможно, использовал бы термин «адаптер». Как отмечали другие, Java предоставляет класс MouseAdapter , который делает то, что вы хотите. Строго говоря, это не совсем подпадает под определение шаблона адаптера, который преобразует один API в другой, но, честно говоря, я склонен прагматично называть такие вещи.

Вероятно, самое важное, что нужно сделать, - это прояснить что вы предполагаете, что метод не будет реализован. В конкретном случае MouseAdapter вы, вероятно, не захотите бросать UnsupportedOperationException , но в целом это, вероятно, хороший сигнал о том, что вы не собираетесь предоставлять реализация. Комментарий в исходном коде (а лучше,