Estou em um projeto que está com sérios problemas de performance e esse projeto tem uma classe com mais de 16000 linhas!!!
De cara acho isso totalmente anormal.
Observando a classe notei que ela tem muitas inner classes.
O sistema é um cliente feito com ADF swing e essa classe contem os listeners de tudo o que acontece no sistema dividido em suas inners classes.
[color=blue][list]Me parece uma péssima prática, o que vocês acham?[/list]
[list]Qual o fundamento ou estudo ou material científico que posso utilizar para aprender sobre isso?[/list]
[list]Me parece que terei que refatorar o sistema, qual a melhor forma de fatiar essa classe?[/list]
[list]Mesmo as inner classes sendo compiladas em arquivos diferentes eu terei problema de performance relacionado com essa classe? Ou o problema é só de desenvolvimento mesmo?[/list]
[list]Quais as implicações dessa classe tão grande?[/list]
[list]Como ela funciona na JVM?[/list][/color]
Problema de performance geralmente não tem a ver com o número de linhas num arquivo. Os arquivos gerados pelo antlr, por exemplo, são gigantescos e tem excelente performance.
Geralmente é. Mas classes geradas por editores automáticos podem ficar bastante grandes. Nesse caso, é bom muda-las apenas no editor onde foram geradas.
Leia o livro Refatoração, do Martin Fowler. Há diferentes estratégias para os diferentes tipos de coisas que vc encontrar na classe.
Nem um, nem outro. Se você tem problemas de performance, use um profiler.
Fica difícil de ler. Pode esbarrar no limite de linhas de um método da JVM.
Exatamente igual a uma classe pequena. Até pq, pelo que vc falou, são várias classes num arquivo só (uma classe e várias inner classes).
Acontece muito em sistemas Java Estruturados (e acredite, eles estão mais presente do que se imagina).
Nao é pq um Sistema está construído com classes, ou alguns objetos “helpers”, que seu sistema é Orientado a Objetos.
Grande parte dos Sistemas Java poderiam ser substituidos por “Packages + Functions + Structs”. Rsrsrsrs
Refatorar uma classe de 16.000 linhas pode ser uma tarefa árdua e que exige experiencia.
Mas siga as dicas acima do Viny e tudo vai dar certo.
:shock:
16000 linhas ? Temos aqui na empresa um sistema com uma classe de ~ 4000 linhas e eu já entro em pânico quando tenho que dar alguma manutenção nela.
Boa sorte na sua refatoração cara, vc vai precisar.
Como o Viny disse nao existe nenhum problema tecnico com uma classe de 16000 linhas. Este nao eh o motivo dos problemas de performance da aplicacao, entao quebra-la em classes menores nao vai ajudar, nem atrapalhar NESTE PONTO.
Use um profiler, como ja foi recomendado, para descobrir os problemas de performance, se este problema for urgente, depois refatore as classes aos poucos a medida que for mexendo nela para fazer alteracoes.
Mas entenda bem, os problemas de desempenho que voce tem nao sao relacionados ao design da classe, mas sim sao ocasionados pela implementacao dela.
É verdade que a perfomance não tem relação com o tamanho em si classe.
Mas o tamanho dela inviabiliza qualquer manutenção ou melhoria. Essa classe suporta uma única tela? Se for esse apenas uma tela é possível negociar com o cliente? Se for apenas uma tela dá pra fazer uma nova proposta de tela em formato wizard ou segregar as funcionalidades em telas menores!!
Considero uma pratica ruim, ao pensar em reusabilidade do código poderemos notar que as coisas podem se complicar.
Siga a super dica do Vini.
Desculpe a sinceridade, ao utilizar as palavras “fatiar essa classe” vc gerou uma certa preocupação. Dividir um arquivo e partes menores não quer dizer que resolveu o problema, já vi casos que a situação ficou muito pior ao fazer isto. É preciso fazer um estudo do problema antes e depois aplicar os conceitos de OO junto com alguns padrões de projeto.
[quote]Mesmo as inner classes sendo compiladas em arquivos diferentes eu terei problema de performance relacionado com essa classe? Ou o problema é só de desenvolvimento mesmo?
[/quote]
Acredito que o problema foi gerado ao desenvolver o código já que a compilação resulta em arquivos menores. Lembrando que parte mais afetada é a reusabilidade do código.
Para chegar nas verdadeiras implicações é preciso fazer uma analise da(s) funcionalidade(s) envolvidas na implementação. Normalmente, pode não ser este seu caso, estas situações leva a geração de um objeto muito grande sem necessidade em alguns momentos. Isto faz com que a memória seja utilizada de forma não otimizada.
