Você vai postar a parte do código que tem ifs aninhados? Porque este código não tem.

Existem alguns ifs que poderiam virar um só, nas duas versões. Não estou dizendo que é a melhor solução porque não tenho todo o contexto, mas daria. De qualquer forma a complexidade ciclomática permaneceria, até porque se o código não é muito mal-feito não tem muito como reduzir essa complexidade.

Na verdade, a complexidade ciclomática, medida da forma correta, está maior no tal código "SOLID".

Eu não chamaria de SOLID algo que simplesmente organizou melhor as responsabilidades. Na minha concepção, mas posso estar enganado por não ter todo o contexto, ainda está misturando as responsabilidades, mesmo que tenha melhorado. Algumas pessoas diriam, eu dou razão em parte a elas, ainda que eu seja um pouco contra o que elas pregam, que o validador ainda tem responsabilidades demais.

Eu não vi a inversão de dependência em desabilitarBotao(), mas posso ter passado batido por ela, poderia me esclarecer? Na classe, será que todas as funções são necessárias ou criou um caso de overengineering, ignorando o YIAGNI? Algo que o DIP tem de belo, permitido na maioria das linguagens, é que dá para colocar depois só se tiver certeza que vai precisar, sem quebrar nada.

Eu gosto de ver essas coisas porque confirma e me dá exemplo do que eu sempre digo, decorar siglas são bem mais fáceis do que fazer o que é certo, inclusive pode ser que nem era necessário o SOLID e gastar tempo com isso. Dependendo do contexto pode acabar sendo a decisão errada, apesar de funcionar. O outro também funcionava.

É o mesmo que sempre falo de OOP. Ela é bem difícil de fazer certo porque as pessoas não conseguem conceber os objetos como eles realmente precisam ser, existem um abismo entre o objeto concreto e a abstração que se faz em código. Isso é pior ainda quando o programador não tem uma experiência absurda com o domínio e os usuários não são absurdamente acima da média. Que é um dos motivos que DDD não costuma dar tão certo. Todas essas ferramentas são ótimas, se não tiver um ser humano para atrapalhar e fazer errado. E mesmo para fazer certo acaba diminuindo a produtividade inicial que é algo que as pessoas dão muito valor. Até os melhores engenheiros erram muito nisso, eu erro muito mais, imagine quem é iniciante, aprendeu os conceitos de forma errada e treinou esses erros o tempo todo e não quer mais procurar o certo. Pode-se ganhar confiança em fazer o errado. E achar que está fazendo algo científico quando na verdade não está.

Tentar deixar SOLID, ainda mais pela metade, só para dizer que fez SOLID, é deixar feio, é piorar a escalabilidade, eventualmente a previsibilidade, pode piorar a manutenção e se fizer muito errado poderá piorar a testabilidade também.

Há quem critique o uso de programação funcional exagerada, especialmente em uma linguagem não funcional e que não tem os mecanismos tão adequados para isso, mas a moda manda fazer assim. Algo a mais para se pensar.

Teste unitário é um único teste. O ideal é fazer testes de unidade. Usar o termo correto é ser científico.

Quais princípios da orientação a objetos foram respeitados, segundo seu texto?

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).