Por favor, não crie abstrações desnecessárias

Gabriel Koerich
2 min readFeb 27, 2016

--

A última vez que vi uma dicussão sobre laravel fiquei um pouco assustado. O pessoal parece levar muito a sério a parte de abstrações e querer criar interfaces e classes completamente desnecessárias.

A dúvida era sobre criar um PostRepositoryInterface, este seria apenas uma abstração para a classe padrão, PostEloquentRepository, que no caso é um wrapper para os métodos do model Post. Existem vários tutoriais por aí dizendo realmente para fazer isso, porque “um dia” “talvez” você “pode querer” mudar sua camada de persistência para utilizar Mongo ou alterar seu ORM. Será mesmo?

A ideia de criar um repositório para o model é interessante. Com o crescimento do projeto o model pode acabar ficando grande demais e difícil de manter. Para evitar repetições no controller, é uma boa prática criar métodos que serão utilizados em diversos locais do projeto no repositório correspondente.

O problema é quando isso vira uma abstração desnecessária. Qual a utilidade de um PostRepositoryInterface, que irá trazer uma instância do PostEloquentRepository? Sua implementação um dia irá mudar? Ninguém costuma mudar o tipo do banco de dados (relacional/não relacional) ou ORM no meio de um projeto. E mesmo assim, se mudar, basta alterar a classe e pronto? É claro que não. Você sabe que não.

Eu parto sempre do princípio que devemos fazer o mínimo de código possível na primeira iteração. Não abstrair em várias interfaces que só terão uma única implementação ou outras classes desnecessárias. No futuro, é muito melhor alterar algo simples e transformar em uma lógica mais robusta do que ter que dar manutenção em uma abstração absurda que você nem lembra mais qual o sentido ou o motivo de ter feito aquilo.

E falo isso por já ter cometido muito esse erro. Por ler muitos livros sobre princípios de desenvolvimento de software achava que tudo tinha que ser levado completamente à risca. Mas nem sempre isso faz sentido. No fim, acabava criando muitas classes e interfaces apenas porque parecia o certo a se fazer.

Alguém ainda poderia defender que toda essa abtração é simplesmente para conseguir alterar a implementação nos testes e não atingir nenhuma camada de persistência ou algo do tipo. Tudo bem, pode até ser. Mas vale esse trade-off? E, na minha opinião, estes testes que utilizam mocks em todas as dependências acabam não testando praticamente nada. Servem somente como testes de erros de digitação. Nesse caso, eu prefiro testes de integração que realmente façam o que um usuário faria no servidor de produção.

Então, por favor. Crie abstrações somente quando forem necessárias. Sabe quando serão necessárias? Quando você criar um método/classe com um typehint e este aceitar mais de uma implementação como parâmetro/dependência. Nesse caso não é apenas válido criar interfaces, mas sim obrigatório. Quando sua aplicação crescer (torceremos que ela irá), você não vai querer ter um monstro, mas sim algo simples que possa ter sua complexidade modificada rapidamente, sem muito stress.

--

--