Una cosa con la que me he encontrado algunas veces es una clase de servicio (como un servicio JBoss) que se ha vuelto demasiado grande debido a las clases internas auxiliares. Todavía tengo que encontrar una buena manera de romper la clase. Estos ayudantes suelen ser hilos. Aquí hay un ejemplo:

/** Asset service keeps track of the metadata about assets that live on other
 * systems. Complications include the fact the assets have a lifecycle and their
 * physical representation lives on other systems that have to be polled to find
 * out if the Asset is still there. */
public class AssetService
{
  //...various private variables
  //...various methods

  public AssetService()
  {
    Job pollerJob = jobService.schedule( new AssetPoller() );
    Job lifeCycleJob = jobService.schedule( AssetLifecycleMonitor() );
  }

  class AssetPoller
  {
    public void run()
    { 
      // contact remote systems and update this service's private variables that
      // track the assets.
    }
  }

  class AssetLifecycleMonitor
  {
    public void run()
    {
      // look for assets that have meet criteria for a lifecycle shift
      // and update this service's private variables as relevant.
    }
  }
}

Entonces, lo que puede suceder si tengo un par de ayudantes y son complejos, es que el archivo de clase general puede ser realmente grande. Me gustan las clases internas porque deja en claro que las clases son propiedad exclusiva del servicio y existen solo para ayudar a ese servicio. He intentado dividir las clases y pasar el servicio principal como referencia, que funciona principalmente, pero las cosas que no me gustan son:

Terminé exponiendo los accesores de nivel de paquete para que las clases desglosadas puedan llegar a las variables, mientras que antes no expuse los establecedores en absoluto ya que las clases internas tenían acceso directo.Además, las cosas se vuelven un poco más complicadas ya que constantemente llamo a los accesores en lugar de las variables subyacentes. Una liendre menor, concedida.Los métodos de conveniencia (por ejemplo, checkAssetIsValid () o algo así) necesitan una exposición a nivel de paquete ahora para que las clases auxiliares puedan llamarlos, donde antes, como clases internas, podrían ser privados.Peor aún, necesito pasar la clase de implementación del servicio a los constructores de clases auxiliares, ya que no quiero exponer estos métodos auxiliares en la interfaz que implementa el servicio porque eso los obliga a ser públicos. Esto puede crear algunos problemas de prueba de unidad / burla.Peor aún, cualquier sincronización que quisiera hacer se filtra a través de algún método de conveniencia externo (por ejemplo, lockDownAssets () durante una actualización de sondeo). Antes, las clases internas tenían acceso a Cerraduras privadas.

En resumen, romper las clases pierde parte de la encapsulación que me gusta. Pero dejarlos adentro puede generar algunos archivos Java grandes. Todavía tengo que encontrar una buena manera de lidiar con esto. C ++ tenía el concepto de "amigos" que rara vez he echado de menos, pero que de hecho ayudaría en este caso.

Pensamientos?