Como você se sente em relação a classes muito longas que contêm entre 2.000 e 4.000 linhas de código?

Negativo.

As classes longas violam o princípio de responsabilidade única (SRP) e o princípio do menor conhecimento (Principle of Least Knowledge). Isso leva aos seguintes problemas:

• Difícil de ler e entender: Um grande volume de código dificulta a percepção da lógica da classe.
• Difícil de manter e modificar: Alterar uma parte da classe pode afetar inadvertidamente outras, causando erros.
• Risco de duplicação de código: Funcionalidades podem se repetir em diferentes partes da classe.
• Problemas com testes: Testes unitários de uma classe grande tornam-se complicados e trabalhosos.
• Redução da reutilização: É difícil extrair e usar partes da funcionalidade em outros locais.

Idealmente, as classes devem ser curtas e realizar uma tarefa específica. A funcionalidade deve ser decomposta em classes ou funções menores e especializadas. A refatoração de tais classes "divinas" é uma prioridade para melhorar a qualidade da base de código.

Para decompor, podem-se usar as seguintes abordagens:

• Separar a lógica relacionada em classes independentes: Por exemplo, manipulação de dados, lógica de UI, lógica de negócio.
• Aplicar padrões de projeto: MVC, MVP, MVVM, Repositório, Factory, etc.
• Dividir em funções/métodos menores: cada método deve fazer uma coisa.
• Usar extensões em Kotlin: para adicionar funcionalidades sem modificar a classe original.