“Orientado a objetos demais”

Eu tenho uma sólida formação em OO e recentemente comecei a trabalhar em uma organização que, embora o código seja escrito em Java, tem muito menos ênfase no bom design de OO do que estou acostumado. Foi-me dito que eu introduzo "muita abstração" e, em vez disso, deveria codificar da maneira que sempre foi feita, que é um estilo de procedimento em Java.

O TDD também não é muito praticado aqui, mas quero ter um código testável. Enterrar a lógica de negócios em métodos privados estáticos em grandes "classes de Deus" (que parece ser a norma para essa equipe) não é muito testável.

Eu luto para comunicar claramente minha motivação aos meus colegas de trabalho. Alguém tem algum conselho sobre como convencer meus colegas de trabalho de que o uso de OO e TDD leva a códigos de manutenção mais fácil?

Esta pergunta sobre dívida técnica está relacionada à minha pergunta. No entanto, estou tentando evitar a dívida em primeiro lugar, em vez de pagá-la após o fato, que é o que a outra questão aborda.

Você não reclamou que isso é insustentável, mas não do seu agrado. Se for uma escolha deliberada de estilo, pode ser apenas um caso de diferenças criativas irreconciliáveis, e você deve ajustar seu estilo para se adequar ou encontrar um local que se encaixe no seu estilo preferido.

As pessoas podem escrever códigos modulares, eficientes, bem abstratos e relativamente livres de erros em um estilo processual o tempo todo. Java é uma escolha estranha de linguagem para essa loja, mas posso ver isso acontecendo se fatores externos decidiram a linguagem, como a necessidade de desenvolver para o Android, por exemplo.

Todo mundo é um gênio. Mas se você julgar um peixe por sua capacidade de escalar uma árvore, ele viverá toda a sua vida acreditando que é estúpido. - Albert Einstein

Se foi uma escolha deliberada, você realmente não pode julgá-los pela aderência a bons princípios de design orientados a objetos; deve avaliar pela aderência a bons princípios de design procedural e refatorar adequadamente. O Java não permite escrever código fora de uma classe, portanto, a mera presença de uma não significa que eles pretendiam que um módulo fosse orientado a objetos.

Por outro lado, se o código estiver uma bagunça em qualquer dos paradigmas, você provavelmente deve apenas reduzir suas perdas.

Lendo sua pergunta, lembrei-me de uma dica do livro Pragmatic Programmer.

Uma de suas dicas é Be a Catalyst for Change:

Você pode estar em uma situação em que sabe exatamente o que precisa ser feito e como fazê-lo. Todo o sistema simplesmente aparece diante dos seus olhos - você sabe que está certo. Mas peça permissão para resolver tudo e você será recebido com atrasos e olhares em branco. As pessoas formarão comitês, os orçamentos precisarão de aprovação e as coisas ficarão complicadas. Todos guardarão seus próprios recursos. Às vezes, isso é chamado de "fadiga inicial".

É hora de cozinhar sopa de pedra. Elabore o que você pode razoavelmente pedir. Desenvolva-o bem. Depois de conseguir, mostre às pessoas e deixe-as se maravilhar. Então diga "é claro, seria melhor se adicionássemos ...". Finja que não é importante. Sente-se e espere que eles comecem a pedir para adicionar a funcionalidade que você queria originalmente. As pessoas acham mais fácil participar de um sucesso contínuo. Mostre a eles um vislumbre do futuro e você os fará se reunir.

Então, acho que se você começar a fazer um bom trabalho com seu conhecimento de OO e TDD, em breve eles começarão a procurar e perguntar sobre o seu trabalho.

Para vender novas maneiras de trabalhar, você precisa mostrar benefícios óbvios. Escrever mais camadas de abstração, sem um benefício claro, mas um vago: "pode ​​ser benéfico para o futuro" não funcionará.

Faça fábricas onde as fábricas produzem mais de um tipo de objeto. Use injeção de dependência, onde ele mostra imediatamente benefícios. Crie interfaces que realmente serão implementadas por mais de uma classe.

O que vejo com muita frequência em "verdadeiro OO" é que técnicas avançadas são usadas para resolver problemas realmente simples de uma maneira excessivamente complexa.

Como você pode mostrar o benefício de uma fábrica se ela apenas produzir o mesmo objeto? Encontre um problema no seu código que se beneficie de técnicas avançadas e mostre seu ponto de vista e trabalhe a partir daí.

As guerras são vencidas uma batalha por vez.

Você só pode convencê-los assumindo um pequeno pedaço de código e implementando TDD e melhores práticas de OO para obter os benefícios. Você os conduziu à terra prometida, e não apenas mostrou bons cartões postais dela.

Certamente, acho que há casos de excesso de abstração em uso em muitas bases de código hoje. Coloque apenas o que você precisa, e isso inclui abstrações.