[Java] ¿Cuándo debería usar una abstract class vs interface?

#9 no son lo mismo y ya han explicado la diferencia en este post.

#13
Y la explicación es?

Pero (y desde el punto de vista de alguien que esta aprendiendo) si yo creo un proyecto nuevo y necesito añadir dependencias de otros que ya tengo, ademas de aparecer en el xml, los objetos y sus métodos aparecen en la clase abstracta. Luego en la interfaz solo tengo la definición del método principal.
Por eso decía que en abstract aparecen las dependencias y así se limpia un poco más el código. Si no es así algo estoy haciendo mal .

#16 no pensaba contestarte, pero... dónde estás aprendiendo eso así?

para #1 , como dicen, intenta ver la diferencia buscando las referencias que te han dado, pero rara vez necesitarás una abstracta hoy en día

#23 Lo que has descrito se parece peligrosamente a un god object.

Incidiendo en el tema del hilo ya que la duda se ha resuelto, no entiendo muy bien lo que dice #5 de que las interfaces casi han sustituido a las clases abstractas. Me explico.

Imagina que tengo un sistema de servicios que se comunican por mensajería. Y que tengo una clase controller en cada servicio que produce mensajes y se queda a la espera de recibir respuesta (de manera asíncrona). Tengo una interfaz IController que declara el método onMessage(), de manera que implemento IController, sobreescribo onMessage() y arreando.

PERO.

Imagina que cada controller es un bean de Spring que se crea cuando se levanta la aplicación y cada controller tiene en su constructor la manera de declarar los exchanges, colas y topics. Es decir, cada controller se configura cuando la aplicación arranca. Esa lógica es común a todos los controladores, todos se configuran igual y sólo cambian las properties.

En ese caso entiendo que una interfaz se me queda corta porque no puedo inyectarle nada, mientras que a una clase abstracta sí. Es decir, que tendría:

public interface IController {
  void onMessage();
}

 public abstract class AbstractController implements IController {

  private ControllerProperties properties;

  public AbstractController(ControllerProperties properties) {
    //Se configura el controlador usando las properties
  }
  

  @Override
  protected abstract void onMessage();
}

 @Controller
public KaledrosController extends AbstractController {

  public Controller(ApplicationContext context) {
    super(context.getBean(KaledrosProperties.class)); //Imagina que KaledrosProperties extiende de ControllerProperties porque cada controller tiene unas properties.
  }

  @Override
  protected void onMessage() {
    //Lo que sea
  }
}

¿O me he perdido algo?

#26 Eso mismo que has puesto, se puede hacer con interfaces a partir de Java 1.8

Tu punto es que AbstractController hace la inicialización común usando el objeto ControllerProperties. Por tanto, en KaledrosController, recibes tu KaledrosProperties, llamas a super para que haga la inicialización común, y a continuación, haces la inicialización propia de KaledrosController. Hasta aquí ok.

Pero fíjate que puedes hacer exactamente lo mismo añadiendo el método configure(ControllerProperties properties) a una interfaz IConfigurer (o lo que sea) con la keyword default. AbstractController implementa IConfigurer y sus hijos, IController. No obstante, este enfoque obliga al desarrollador a conocer que cada hijo de AbstractController debe implementar IController para poder enviar mensajes; con tu ejemplo, debe implementarlo obligatoriamente, lo sepa o no.

El ejemplo se puede hacer de ambas maneras, aunque con la clase abstracta, en este caso, está mejor hecho. Pero ahora planteate que esa inicialización común que haces en AbstractController, cambia o se ramifica. Vas a tener que emplear una nueva estructura de herencia, modificar los controladores base, etc. Usando composición, puedes resolver ese problema de manera más sencilla al tener la lógica de la inicialización separada en interfaces que puedes quitar o añadir sin esfuerzo.