Uma coisa que encontrei algumas vezes é uma classe de serviço (como um serviço JBoss) que ficou muito grande devido a classes internas auxiliares. Ainda estou para encontrar uma boa maneira de começar a aula. Esses ajudantes geralmente são tópicos. Aqui está um exemplo:

/** 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.
    }
  }
}

Então, o que pode acontecer se eu tiver alguns auxiliares e eles forem complexos, é que o arquivo geral da classe pode ficar muito grande. Gosto das classes internas, pois deixa claro que as classes são de propriedade exclusiva do serviço e existem apenas para ajudá-lo. Tentei interromper as aulas e passar o serviço pai como referência, o que funciona principalmente, mas as coisas que eu não gosto são:

Acabo expondo os acessadores no nível do pacote para que as classes divididas possam chegar às variáveis, enquanto antes eu não expunha os setters, pois as classes internas tinham acesso direto.Além disso, as coisas ficam um pouco mais complicadas, pois estou constantemente chamando os acessadores em vez das variáveis subjacentes. Um nit menor, concedido.Os métodos de conveniência (por exemplo, checkAssetIsValid () ou algo parecido) precisam de exposição no nível do pacote agora para que as classes auxiliares possam chamá-los, onde antes, como classes internas, poderiam ser particulares.Pior ainda, preciso passar a classe de implementação de serviço para os construtores de classes auxiliares, pois não quero expor esses métodos auxiliares na interface implementada pelo serviço, porque isso os força a serem públicos. Isso pode criar alguns problemas de teste / simulação de unidade.Pior ainda, qualquer sincronização que eu quis fazer vazou através de algum método de conveniência externo (por exemplo, lockDownAssets () durante uma atualização de pesquisa). Antes, as classes internas tinham acesso a bloqueios particulares.

Então, resumindo, quebrar as classes perde parte do encapsulamento que eu gosto. Mas deixá-los dentro pode levar a alguns arquivos java grandes. Ainda estou para encontrar uma boa maneira de lidar com isso. O C ++ tinha o conceito de "amigos" que raramente perdi, mas que na verdade ajudaria nesse caso.

Pensamentos?