在Abstract类上实现侦听器是个好主意吗？

Question

我正在为当前使用Java（这里是新手程序员）的游戏编写代码， 但是我不确定是否存在危险或好处，或者如果应该的话，不确定是否具有初始化显示模式并进入游戏循环的抽象类 ，该类实现了关键侦听器用于控制

Answer 1

Abstract Class is between Interface and and BaseClass ie it may have some implemented methods and some unimplemented methods.

All methods of sub classes which have common implementation can be implemented in Abstract class itself.

If you think your Listener implementation is common across most of the implementing implementing classes of the abstract class, then I think it's completely fine to define the listener in the abstract class. If implementation is not same but the same method is required in most of the implementing classes, then define the signature as an abstract method in the abstract class. If nothing is common, then I think you had better not have it in the abstract class.

Answer 2

There are two reasons (that I can think of) you want to prefer interfaces over abstract classes for your listeners.

1. If you have multiple listeners that are all marked abstract, a class can only inherit from one, even though it may make sense for a class to implement multiple listeners.

2. You may have an existing class that's already inheriting from another class, but you'd also like to be able to mark it as a listener.

If you decide on using an interface but still wish to share some common implementation, a pattern to accomplish this is to create both a listener interface and an abstract implementation, eg

interface ClickListener {
  void onLeftClickPressed();
  void onLeftClickReleased();
}

// "DefaultClickListener" and "AbstractClickListener" are also common conventions
abstract class DoubleClickListener implements ClickListener {
  int leftClickCount;
  @Override public final void onLeftClickPressed() {
    ++leftClickCount;
    if (leftClickCount == 2) {
      onDoubleClicked();
    }
  }
  @Override public final void onLeftClickReleased() { --leftClickCount; }

  protected abstract void onDoubleClicked();
}

If your listener interface has multiple methods, it can be nice to provide an adapter version that provides stubbed implementation for all of them, eg

interface ComplexListener {
  void onEvent1();
  ...
  void onEvent100();
}

abstract class ComplexListenerAdapter implements ComplexListener {
  @Override public void onEvent1() {}
  ...
  @Override public void onEvent100() {}
}

final class MySimpleListener extends ComplexListenerAdapter {
  // The only event I care about
  @Override public void onEvent42() { ... }
}

I'm not sure it's a standard convention, but I've seen the ListenerAdapter name used for these sorts of listener implementations.

Answer 3

an abstract class is a class whose object can't be instantiated, for a key listener for any controls you need to include every definition of the game into a class or an abstract class whichever you use and that includes the Listener.

for any object which class to model how depends on whether there is any object who plays any role in the game, for eg some classes are meant to be parent classes, the HumanBeing class in any project you won't create an object of human being class, you'll surely extend it to Man, Worker, Woman etc so let HumanBeing be an abstract class

so that is data modelling part. and i am sorry i was wrong when i stated in my previous answer that you can't add a Listener to a abstract class, you surely can but you have to take into consideration which classes to make and what are the roles of the classes only then you can decide if or not to include Listener into Abstract class ( part of Software Engineering)