Às vezes, no fluxo do desenvolvimento, a gente acaba seguindo pelo caminho mais rápido: o famoso Control + C / Control + V. Recentemente, me vi nessa situação enquanto criava em um app em Flutter. Eu precisava de três feeds diferentes: um para usuários seguidos, um local e um global.
O Problema: A Armadilha da Repetição
Na primeira versão, eu tinha três arquivos separados: HomeFeedScreen, LocalFeedScreen e GlobalFeedScreen. Toda vez que eu decidia adicionar uma funcionalidade nova — como um botão de “curtir” ou “reblog”— eu era obrigado a replicar o código nos três arquivos.
A Solução: Herança e Classes Abstratas
Para resolver isso, decidi aplicar um conceito fundamental da Orientação a Objetos: a abstração.
Em vez de três telas independentes, criei uma classe abstrata que estende o State do Flutter. Essa classe pai contém toda a inteligência comum aos feeds: controle de scroll, gerenciamento de listas e tratamento de erros.
O “pulo do gato” foi declarar um método abstrato chamado fetchPosts().
Como ficou o código (na prática)
A estrutura ficou mais ou menos assim:
- As Classes Filhas (A Especialização): Agora, LocalFeedScreen, HomeFeedScreen e GlobalFeedScreen são extremamente enxutas. Elas apenas estendem a classe pai e implementam a função fetchPosts, chamando o endpoint específico de cada uma.
- A Classe Pai (O Molde): Ela cuida de tudo o que é repetitivo. Ela sabe como exibir os posts, mas não sabe quais posts buscar.
O Resultado
Agora, se eu quiser mudar a função do feedPost eu mudo em um único lugar. O código ficou mais limpo, mais fácil de ler e, acima de tudo, escalável.Ainda pretendo melhorar a organização e talvez explorar outras formas de gerenciamento de estado, mas o simples fato de ter eliminado a redundância técnica (o famoso princípio DRY – Don’t Repeat Yourself) já transformou a manutenção desse projeto em algo muito mais prazeroso.