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.