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/informação sobre o domínio/regras de negócio 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.
Top comments (0)