Orientação a objetos == trabalho em equipe

Hoje, durante o banho, concluí algo que achei interessante o suficiente para vir escrever aqui no blog.

Código bem orientado a objetos é igual a trabalho em equipe. Cada classe faz uma pequena parte do trabalho e nenhuma é mais importante do que as outras. Juntas é que são poderosas; sozinhas, não são grande coisa.

Código sequencialzão é exatamente o oposto. É igual a trabalho individualista. As classes/funções fazem muita coisa, sabem muita coisa, carregam muito peso. E têm dificuldade de interagir. Sozinhas é que são poderosas; juntas, não são grande coisa.

Ministro a disciplina de Programação Orientada a Objetos e percebo que muitos alunos têm dificuldade de entender conceitos como herança, polimorfismo, coesão e acoplamento. Eles às vezes acham essas coisas meio complicadas. Ao implementar novas funcionalidades em um sistema, em vez de repensar a estrutura, preferem escrever mais linhas de código nos métodos já existentes. E, assim, surgem vários novos comandos if, else e new, aumentando complexidade e acoplamento.

Quando você faz software no mundo real, você nunca faz tudo sozinho. Em vez disso, usa a biblioteca-padrão e/ou bibliotecas externas, troca ideias com os colegas, adota padrões de design

É por isso que orientação a objetos é importante. Vale a pena o trabalho extra de criar interfaces, injetar dependências, reduzir acoplamento, aumentar coesão e usar padrões? A resposta geralmente é… SIM! Porque, no mundo real, a gente trabalha em equipe. Mesmo que essa equipe seja apenas você, sua linguagem de programação e seu framework web. Já será o suficiente para precisar de uma divisão do trabalho. E, para dividir o trabalho no código, nada melhor que interfaces, coesão e padrões de design.

Trabalhar em equipe desonera os indivíduos, mas onera a integração. Código sequencialzão é difícil de manter, mas é fácil de escrever. Tudo tem seu preço, assim na Terra como no software.

(Alguma semelhança com a discussão “microsserviços x arquiteturas monolíticas”?)