DEV Community

loading...

Algumas das fases que passei no aprendizado de programação orientada a objetos

Raphael da Silva
Updated on ・2 min read

Eu passei por algumas fases diferentes no aprendizado para tentar ter um código mais orientado a objetos (desde 2014). Entre essas fases então:

  • Quase desistir de um curso técnico em 2011 quando tive o primeiro contato com a orientação a objetos.

  • Aprender a fazer algumas classes ruins (usando varíaveis globais para passar a pdo para a classe) e (achar esse código ruim) o máximo.

  • Insistir em estudar e começar a ter mais conforto com objetos por volta da metade de 2013.

  • Ter um código com muita herança, onde tudo estava estendendo de um model mais genérico que era gigante.

  • Entender injeção de dependência se empolgar e querer parametrizar tudo (até o que nem precisaria variar).

  • Criar um framework próprio (aka framework caseiro) em 2014 e se empolgar (atualizando o código com o que eu ia aprendendo).

  • Ler muitos artigos que questionam getters, setters, entidades e outras práticas e achar que tinha descoberto o jeito "certo" e passar a achar que determinadas práticas são sempre ruins sem analisar.

  • Ler muitos artigos e achar que código estáticos são sempre ruins, o que é uma generalização sem análise da situação.

  • Eu gosto muito do conceito de interfaces, logo acabei criando interfaces para todas as classes, até as que não precisariam de uma interface por não exigirem novas implementações diferentes.

  • Ter interfaces e classes com o mesmo nome separadas por um prefixo I e não enxergar que isso era um sinal de erro de abstração.

  • Começar a rever as minhas posturas sobre as opniões que eu tinha formado e ir ficando menos intrasigente (mais flexível). Com isso, comecei a reavaliar as práticas que eu aplicava cegamente. Disso surgiram as etapas a seguir.

  • Ver que código estático nem sempre é um problema e pode ser aplicado para coisas simples como factorys e operações simples que agem com funções e não precisam ser trocados (através de injeção de dependência).

  • Ver que nem toda classe precisa de interface para variar a sua implementação.

  • Usar array para tudo e achar entidades desnecessárias pela complexidade adicionada (sem enxergar o contexto sobre o domínio que elas dão).

As mudanças de 2020

Antes eu acha que para seguir DIP era só depender de abstrações com uma interface e classe abstrata, sem entender a relação entre o que está baixo nível (infraestrutura) e o que está alto nível (domínio).

Depois disso passei a buscar expressar o domínio de forma mais intuitiva e nítida, por isso estou tentando usar alguns conceitos mais simples de DDD (entidades, value objects).

Junto com os conceitos de DDD também estou tentando aplicar a separação do código de infraestrutura e domínio, pois só depois dessa separação eu comecei a entender o que realmente significa o princípio da inversão de dependência do SOLID.

Discussion (0)

Forem Open with the Forem app